Some cleanups and additions

app-emulation/puae : Ebuild updated to newer version
app-emulation/winetricks : Old ebuild removed

All folders now have a first version of metadata.xml and ChangeLog

TODO:
- Digest all
- Add missing cresdits to ChangeLogs where ebuilds have been modified
  rather then written from scratch.
- Overwrite metadata.xml where there are other versions in the tree
  and/or sunrise overlay

5 files changed, 269 insertions, 0 deletions

diff --git a/games-strategy/freeorion/ChangeLog b/games-strategy/freeorion/ChangeLog
new file mode 100644
index 0000000..6eff27d
--- /dev/null
+++ b/games-strategy/freeorion/ChangeLog
@@ -0,0 +1,67 @@
+# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
+# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
+# $Header: $
+
+*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
+  Initial import.  Ebuild submitted by submitter_name <submitter_email>.
+  Note that the "changed_file" listing is optional if you are simply bumping
+  the rev of the ebuild and are only making changes to the .ebuild file
+  itself.  Also note that we now have a single unified paragraph rather than
+  having the first line separated from the rest by a newline.  Everything
+  should be in one block like this. (note by drobbins, 16 Jul 2002)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
+  an earlier ChangeLog entry.
+
+-- Explanation of ChangeLog format:
+
+  ***************************************************************************
+  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
+  changes made to a set of ebuilds. That means that the most recent ChangeLog
+  entry *always* goes at the top of the file. More explanation below.
+  ***************************************************************************
+
+  ***************************************************************************
+  ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
+  format and organize all changes under the "correct" "*" entry. This is not
+  correct. However, rather than making a concerted effort to fix these
+  ChangeLogs, we should spend our energy defining a comprehensive and strict
+  XML-based ChangeLog format which we then migrate to. But for any entries to
+  any ChangeLog that *you* make, please make sure to always add entries to the
+  top of the file like a good boy/girl. Even do this if it's clear that you're
+  adding an entry to a b0rked ChangeLog.
+  ***************************************************************************
+
+  This changelog is targeted to users. This means that the comments should be
+  well explained and written in clean English.
+
+  Every new version or revision of the package should be marked by a '*'
+  separator line as above to indicate where in the chronology it was first
+  added to our CVS tree. Any changes since the last revision, really _any
+  changes at all_ have to be added to the top of the file, underneath the
+  initial copyright and cvs header comments, in exactly the same format as this
+  comment. If you are modifying older ebuilds, simply note them as changed
+  files and add your entry to the top of the ChangeLog. Resist the temptation
+  to "organize" your ChangeLog entries by placing them under the "correct" "*"
+  entries -- this isn't the purpose of the "*" entries.
+
+  This means that you start with header line that has the following format,
+  indented two spaces:
+
+  DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
+  explanation should follow. It should be indented and wrapped at a line width
+  of 80 characters.  The changed_files can be omitted if they are obvious; for
+  example, if you are only modifying the .ebuild file and committing a new rev
+  of a package.  Any details about what exactly changed in the code should be
+  added as a message when the changes are committed to cvs, not in this file.
+
+-- A word regarding credit:
+
+  Please add credit information ("ebuild submitted by ...", "patch submitted
+  by ...") to the ChangeLog. Do not add this information to the ebuilds
+  themselves.
+
+  And remember: Give credit where credit is due. We're all doing this for
+  free, so the best we can hope (and expect!) to receive is credit.
diff --git a/games-strategy/glfrontier/ChangeLog b/games-strategy/glfrontier/ChangeLog
new file mode 100644
index 0000000..6eff27d
--- /dev/null
+++ b/games-strategy/glfrontier/ChangeLog
@@ -0,0 +1,67 @@
+# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
+# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
+# $Header: $
+
+*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
+  Initial import.  Ebuild submitted by submitter_name <submitter_email>.
+  Note that the "changed_file" listing is optional if you are simply bumping
+  the rev of the ebuild and are only making changes to the .ebuild file
+  itself.  Also note that we now have a single unified paragraph rather than
+  having the first line separated from the rest by a newline.  Everything
+  should be in one block like this. (note by drobbins, 16 Jul 2002)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
+  an earlier ChangeLog entry.
+
+-- Explanation of ChangeLog format:
+
+  ***************************************************************************
+  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
+  changes made to a set of ebuilds. That means that the most recent ChangeLog
+  entry *always* goes at the top of the file. More explanation below.
+  ***************************************************************************
+
+  ***************************************************************************
+  ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
+  format and organize all changes under the "correct" "*" entry. This is not
+  correct. However, rather than making a concerted effort to fix these
+  ChangeLogs, we should spend our energy defining a comprehensive and strict
+  XML-based ChangeLog format which we then migrate to. But for any entries to
+  any ChangeLog that *you* make, please make sure to always add entries to the
+  top of the file like a good boy/girl. Even do this if it's clear that you're
+  adding an entry to a b0rked ChangeLog.
+  ***************************************************************************
+
+  This changelog is targeted to users. This means that the comments should be
+  well explained and written in clean English.
+
+  Every new version or revision of the package should be marked by a '*'
+  separator line as above to indicate where in the chronology it was first
+  added to our CVS tree. Any changes since the last revision, really _any
+  changes at all_ have to be added to the top of the file, underneath the
+  initial copyright and cvs header comments, in exactly the same format as this
+  comment. If you are modifying older ebuilds, simply note them as changed
+  files and add your entry to the top of the ChangeLog. Resist the temptation
+  to "organize" your ChangeLog entries by placing them under the "correct" "*"
+  entries -- this isn't the purpose of the "*" entries.
+
+  This means that you start with header line that has the following format,
+  indented two spaces:
+
+  DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
+  explanation should follow. It should be indented and wrapped at a line width
+  of 80 characters.  The changed_files can be omitted if they are obvious; for
+  example, if you are only modifying the .ebuild file and committing a new rev
+  of a package.  Any details about what exactly changed in the code should be
+  added as a message when the changes are committed to cvs, not in this file.
+
+-- A word regarding credit:
+
+  Please add credit information ("ebuild submitted by ...", "patch submitted
+  by ...") to the ChangeLog. Do not add this information to the ebuilds
+  themselves.
+
+  And remember: Give credit where credit is due. We're all doing this for
+  free, so the best we can hope (and expect!) to receive is credit.
diff --git a/games-strategy/glfrontier/metadata.xml b/games-strategy/glfrontier/metadata.xml
new file mode 100644
index 0000000..46a44e5
--- /dev/null
+++ b/games-strategy/glfrontier/metadata.xml
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<!-- 
+$Header: /var/cvsroot/gentoo-x86/skel.metadata.xml,v 1.18 2008/07/28 19:27:05 cardoe Exp $
+
+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/devrel/handbook/handbook.xml?part=2&chap=4
+
+
+Before committing, please remove the comments from this file. They are 
+not relevant for general metadata.xml files.
+-->
+<pkgmetadata>
+<herd>no-herd</herd>
+<maintainer>
+  <email>@gentoo.org</email>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+<!--
+<use>
+  <flag name='flag'>Description of how USE='flag' affects this package</flag>
+  <flag name='userland_GNU'>Description of how USERLAND='GNU' affects this
+	  package</flag>
+  <flag name='aspell'>Uses <pkg>app-text/aspell</pkg> for spell checking.
+	  Requires an installed dictionary from <cat>app-dicts</cat></flag>
+</use>
+-->
+</pkgmetadata>
diff --git a/games-strategy/seven-kingdoms/ChangeLog b/games-strategy/seven-kingdoms/ChangeLog
new file mode 100644
index 0000000..6eff27d
--- /dev/null
+++ b/games-strategy/seven-kingdoms/ChangeLog
@@ -0,0 +1,67 @@
+# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
+# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
+# $Header: $
+
+*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
+  Initial import.  Ebuild submitted by submitter_name <submitter_email>.
+  Note that the "changed_file" listing is optional if you are simply bumping
+  the rev of the ebuild and are only making changes to the .ebuild file
+  itself.  Also note that we now have a single unified paragraph rather than
+  having the first line separated from the rest by a newline.  Everything
+  should be in one block like this. (note by drobbins, 16 Jul 2002)
+
+  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
+  an earlier ChangeLog entry.
+
+-- Explanation of ChangeLog format:
+
+  ***************************************************************************
+  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
+  changes made to a set of ebuilds. That means that the most recent ChangeLog
+  entry *always* goes at the top of the file. More explanation below.
+  ***************************************************************************
+
+  ***************************************************************************
+  ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
+  format and organize all changes under the "correct" "*" entry. This is not
+  correct. However, rather than making a concerted effort to fix these
+  ChangeLogs, we should spend our energy defining a comprehensive and strict
+  XML-based ChangeLog format which we then migrate to. But for any entries to
+  any ChangeLog that *you* make, please make sure to always add entries to the
+  top of the file like a good boy/girl. Even do this if it's clear that you're
+  adding an entry to a b0rked ChangeLog.
+  ***************************************************************************
+
+  This changelog is targeted to users. This means that the comments should be
+  well explained and written in clean English.
+
+  Every new version or revision of the package should be marked by a '*'
+  separator line as above to indicate where in the chronology it was first
+  added to our CVS tree. Any changes since the last revision, really _any
+  changes at all_ have to be added to the top of the file, underneath the
+  initial copyright and cvs header comments, in exactly the same format as this
+  comment. If you are modifying older ebuilds, simply note them as changed
+  files and add your entry to the top of the ChangeLog. Resist the temptation
+  to "organize" your ChangeLog entries by placing them under the "correct" "*"
+  entries -- this isn't the purpose of the "*" entries.
+
+  This means that you start with header line that has the following format,
+  indented two spaces:
+
+  DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
+  explanation should follow. It should be indented and wrapped at a line width
+  of 80 characters.  The changed_files can be omitted if they are obvious; for
+  example, if you are only modifying the .ebuild file and committing a new rev
+  of a package.  Any details about what exactly changed in the code should be
+  added as a message when the changes are committed to cvs, not in this file.
+
+-- A word regarding credit:
+
+  Please add credit information ("ebuild submitted by ...", "patch submitted
+  by ...") to the ChangeLog. Do not add this information to the ebuilds
+  themselves.
+
+  And remember: Give credit where credit is due. We're all doing this for
+  free, so the best we can hope (and expect!) to receive is credit.
diff --git a/games-strategy/seven-kingdoms/metadata.xml b/games-strategy/seven-kingdoms/metadata.xml
new file mode 100644
index 0000000..46a44e5
--- /dev/null
+++ b/games-strategy/seven-kingdoms/metadata.xml
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<!-- 
+$Header: /var/cvsroot/gentoo-x86/skel.metadata.xml,v 1.18 2008/07/28 19:27:05 cardoe Exp $
+
+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/devrel/handbook/handbook.xml?part=2&chap=4
+
+
+Before committing, please remove the comments from this file. They are 
+not relevant for general metadata.xml files.
+-->
+<pkgmetadata>
+<herd>no-herd</herd>
+<maintainer>
+  <email>@gentoo.org</email>
+<!--  <description>Description of the maintainership</description> -->
+</maintainer>
+<!-- <longdescription>Long description of the package</longdescription> -->
+<!--
+<use>
+  <flag name='flag'>Description of how USE='flag' affects this package</flag>
+  <flag name='userland_GNU'>Description of how USERLAND='GNU' affects this
+	  package</flag>
+  <flag name='aspell'>Uses <pkg>app-text/aspell</pkg> for spell checking.
+	  Requires an installed dictionary from <cat>app-dicts</cat></flag>
+</use>
+-->
+</pkgmetadata>