]> Pileus Git - ~andy/sunrise/commitdiff
nuke tons of cruft from ChangeLog
authorJakub Moc <jakub@gentoo.org>
Wed, 27 Dec 2006 23:00:05 +0000 (23:00 +0000)
committerJakub Moc <jakub@gentoo.org>
Wed, 27 Dec 2006 23:00:05 +0000 (23:00 +0000)
svn path=/sunrise/; revision=2507

app-backup/darbackup/Changelog
app-backup/darbackup/Manifest

index a23f4e1815b407b2aedd2503cfac94d00906c594..0e04f1a3773ef7ead42640d26e9f8eaac3debbda 100644 (file)
@@ -1,9 +1,7 @@
-# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
+# ChangeLog for app-backup/darbackup
 # Copyright 1999-2006 Gentoo Foundation; Distributed under the GPL v2
 # $Header: $
 
-*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
-
   27 Dec 2006; Eduard Warkentin <eduard.warkentin@gmx.de> :  Initial import.
   Ebuild submitted by Eduard Warkentin <eduard.warkentin@gmx.de>.
   Note that the "changed_file" listing is optional if you are simply bumping
   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)
 
--- 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.
index ee3b4d8ad5bfee349f11676160bdec9d1aa2890b..eb4663e94fd79b2289b9c43f11283b32f2684df6 100644 (file)
@@ -2,10 +2,10 @@ EBUILD darbackup-0.7.ebuild 629 RMD160 7fc77d196ad478665b3bce5b154323b9dc62deb3
 MD5 33ecf34ec0da6d867f7a4de83016e52f darbackup-0.7.ebuild 629
 RMD160 7fc77d196ad478665b3bce5b154323b9dc62deb3 darbackup-0.7.ebuild 629
 SHA256 e507fac4b372928fbbf1c22db4d1b0d6c172104a61b5efdef000f4fcf55e491b darbackup-0.7.ebuild 629
-MISC Changelog 3559 RMD160 07e6ab1e02d3e5fd31cec8265294bacd88ed914a SHA1 5cc577e4c0c06ca75ad2ac631b19ae1dddb5e9ac SHA256 0ab0956ceb40b6bec532a7e0bc3bcaff2fbd1cd0bae5e444ab100ec35efa6553
-MD5 0c25f708ee1f93ded69a02e077f2685b Changelog 3559
-RMD160 07e6ab1e02d3e5fd31cec8265294bacd88ed914a Changelog 3559
-SHA256 0ab0956ceb40b6bec532a7e0bc3bcaff2fbd1cd0bae5e444ab100ec35efa6553 Changelog 3559
+MISC Changelog 633 RMD160 ab53364a8410d2dd44cdab60021f68edbd27e200 SHA1 456d59453c4e37b93bc7832c46615bd28abcf4c5 SHA256 c299dd9c843a6330ec3cbdf888da518f570e2b5d0e540f692d50a1fa474efd59
+MD5 adfd0f278e709d2f5d5986b0ac034e9e Changelog 633
+RMD160 ab53364a8410d2dd44cdab60021f68edbd27e200 Changelog 633
+SHA256 c299dd9c843a6330ec3cbdf888da518f570e2b5d0e540f692d50a1fa474efd59 Changelog 633
 MISC metadata.xml 170 RMD160 645927a396fdc21cdeb089fe42c5397332420ea6 SHA1 ac7f48a14fec325926f9ce1be8fbf1f311b4f2e4 SHA256 d797a2ec6f9dc516c9f9c1a758ee87ad3e8c43101b5dc76c2f872d5bd4639b42
 MD5 1e678929a9fec6632e227bdf2262e9a1 metadata.xml 170
 RMD160 645927a396fdc21cdeb089fe42c5397332420ea6 metadata.xml 170