Git-Url: 
http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=commitdiff;h=58ca9ec6c5c69d8183de4af843dfc3fe3a529c18

commit 58ca9ec6c5c69d8183de4af843dfc3fe3a529c18
Author: Russell Dickenson (phayz) <[email protected]>
Date:   Thu Apr 2 21:01:29 2009 +1000

Grammatical and spelling changes

modified:   develfaq.txt
modified:   getting-involved.txt
modified:   gnome-bump-howto.txt
modified:   gpg.txt
modified:   introduction.txt
modified:   list-rules.txt
modified:   make-translation-for-rc-scripts.txt
modified:   mobile.txt
modified:   pacman-g2.txt
modified:   repos.txt
modified:   testsuite.txt

diff --git a/docs/develfaq.txt b/docs/develfaq.txt
old mode 100644
new mode 100755
index db0079a..7a37056
--- a/docs/develfaq.txt
+++ b/docs/develfaq.txt
@@ -20,20 +20,21 @@ you should write

in your FrugalBuild.

-== I can't pacman-g2 -Su <package>, it says local version is newer, but I know 
it isn't!
+== I can't pacman-g2 -Su <package>, it says local version is newer, but I know
+it isn't!

-This is a bug in the package's version numbering, the maintainer should
-bothered with this. Since pacman-g2 checks the version numbers (installed vs.
-repo version), the new package's version should be bigger than the old one
-to upgrade flawlessly.
+This is a bug in the package's version numbering, so please report this in the
+Bug Tracker System. Since pacman-g2 checks the version numbers (installed vs.
+repo version), the new package's version must be bigger than the old one to
+upgrade flawlessly.

== What does 5.55 SBU mean?

-It took 5.55 times longer to compile the package by the maintainer
-than binutils. So if you want to know how much will it take to compile
-a package with 5.55 SBU, you should first compile binutils (makepkg helps
-you, as it writes how many seconds elapsed). Then you should multiply it
-by 5.55 to know how many seconds will it take to compile the package.
+It took 5.55 times longer for the maintainer to compile this package than
+binutils. So if you want to know how long it will take to compile a package
+with 5.55 SBU, you should first compile binutils (makepkg helps you, as it
+writes how many seconds elapsed). Then you should multiply it by 5.55 to know
+how many seconds it will take to compile the package.

== Why do maintainers cry about my new package's tarball?

@@ -48,16 +49,16 @@ eaccelerator/README.Frugalware
eaccelerator/eaccelerator-0.9.3-1-i686.fpm
------------------------------------------

-You have to name the tarball as
-<pkgname>-<pkgver>-<pkgrel>.tar.bz2 (or gz), which should only
-contain a <pkgname> directory at first level, and all the files needed to
- create the fpm in it. It is the easiest way for the maintainers to work
- with your tarball when addig your package to the repo.
+You have to name the tarball as <pkgname>-<pkgver>-<pkgrel>.tar.bz2 (or gz),
+which should only contain a <pkgname> directory at first level, and all the
+files needed to  create the fpm in it. It is the easiest way for the
+maintainers to work with your tarball when adding your package to the repo.

-== What should I include in depends(), rodepends() and makedepends() and what 
shouldn't?
+== What should and shouldn't I include in depends(), rodepends() and
+makedepends()?

-You shouldn't include any trivial makedepends, you should only include what
- chkdep -p recommends. Trivial makedepends:
+You should include only what chkdep -p recommends, and avoid trivial
+makedepends, including:

* auto*
* make
@@ -73,13 +74,14 @@ the given application.

== What are the various dependancy-control arrays for?

-* 'depends' should contain any packages that this one depends on a compile and 
run time as well.
+* 'depends' should contain any packages that this one depends on at compile and
+run time as well.
* 'makedepends' is for packages that this one needs to compile.
* 'rodepends' is for run time only dependencies;
eg. a wordlist package (with no executables) needs a program
which can handle it as a dictionary.
* 'provides' is an alternate name for the package. Main use is for
-more packages which do the same; eg. hunspell-en and hunspell-de both provides
+more packages which do the same; eg. hunspell-en and hunspell-de both provide
hunspell-dict, and hunspell depends on hunspell-dict instead of any specific
language. (Sometimes those packages are conflicting, like postfix provides
_and_ conflicts with mta, and exim too - this way there can be only one MTA on
@@ -88,16 +90,18 @@ the system, without the need to know other MTAs' name.)
Be careful with dependency-cycles: while pacman-g2 can handle them, makepkg can
not.

-== How can I have PHP to work with my newly packaged eaccelerator/anything 
extension?
+== How can I have PHP to work with my newly packaged eaccelerator/anything
+extension?

-Since package A should not tamper with package B's config files,
-you should write a README.Frugalware, describing how to enable/use
-the extension, include it in source() and Fdoc README.Frugalware.
+Since package A should not tamper with package B's config files,you should 
write
+a README.Frugalware, describing how to enable/use the extension, include it in
+source() and Fdoc README.Frugalware.

-== How can I cross-compile (package) an architecture-independent (non-binary) 
program?
+== How can I cross-compile (package) an architecture-independent (non-binary)
+program?

-You should modify carch and chost in '/etc/makepkg.conf' and
-build the package again.
+You should modify carch and chost in '/etc/makepkg.conf' and build the package
+again.

== repoman upd can't create /var/fst/ as it already exists

@@ -109,7 +113,8 @@ build the package again.

`git clone http://git.frugalware.org/repos/frugalware-current`

-This creates a new local repo for you, which is a copy of the central repo. To 
update it, run
+This creates a new local repo for you, which is a copy of the central repo. To
+update it, run

`git pull --rebase`

@@ -119,14 +124,14 @@ up your name, email, etc.

== What should I write as patch name and long comment at repoman rec?

-Patch name should be the same as the fpm (but without .fpm, of course);
-and long comment should only contain what you have done to create that
-patch (eg. "added i686 to archs()" or alike).
+Patch name should be the same as the fpm (but without .fpm, of course); and 
long
+comment should only contain what you have done to create that patch (eg. "added
+i686 to archs()").

== Where should I place my comments about a package?

-You mean README.Frugalware. It should be in source() and then
-at the end of the build() you should use:
+You mean README.Frugalware. It should be in source() and then at the end of the
+build() you should use:

Fdoc README.Frugalware

@@ -151,48 +156,50 @@ since you don't need this really)...
What is the order of a new package's locales? How should I name them?

Have a look at hunspell There is a hunspell package, which depends on
-hunspell-dict. There is no package named hunspell-dict, but it is provided by 
the
-locale packages. The most important ones are -en (==en_US), -hu (==hu_HU), -de 
(==de_DE),
- -fr (==fr_FR), -it (==it_IT), -es (==es_ES) and -sk (==sk_SK).
-here are others: -en_US, -de_CH, -es_MX.
+hunspell-dict. There is no package named hunspell-dict, but it is provided by
+the locale packages. The most important ones are -en (==en_US), -hu (==hu_HU),
+-de (==de_DE), -fr (==fr_FR), -it (==it_IT), -es (==es_ES) and -sk (==sk_SK).
+Here are others: -en_US, -de_CH, -es_MX.

-The -xx packages will be installed by the non-CD based (ie. netinst, DVD) 
installers.
+The -xx packages will be installed by the non-CD based (ie. netinst, DVD)
+installers.

== Error handling

-You are responsible to check if a command used in build() fails. The best is to
-use the F* macros where possible, they handle the errors for you. If you need
-custom commands, it's recommended to append `|| return 1` to every line, so
-that build() will stop if an error occures.
+You are responsible for checking if a command used in build() fails. The best 
is
+to use the F* macros where possible since they handle the errors for you. If 
you
+need custom commands, it's recommended to append `|| return 1` to every line, 
so
+that build() will stop if an error occurs.

== Permissions

If text files (header files, documentation) are executable, feel free to fix
their permission. A bigger problem is the permission of the shared libraries.
They must be executable, please fix their permission if necessary. As always,
-it's recommended to create a patch to fix the problem and send it to upstream.
+it's recommended to create a patch to fix the problem and send it to the
+upstream project.

-== Striping
+== Stripping

Stripping binaries is unnecessary and pointless. Unless you use
`options=(\'nostrip\')` in the FrugalBuild, it's done by makepkg automatically.

== When should I use $Fsrcdir and $Fdestdir

-Most F* macro will prepend/append those variables for you, but if you use
+Most F* macros will prepend/append those variables for you, but if you use
custom commands, then you always have to use them.

== When should I increment a package's release number?

* If your change affects only the FrugalBuild (like an up2date fix) then you
should not, just push your change.
-* You should do so, if your change affects the fdb or the fpm (change in
-  build(), depends() fix, etc).
+* If your change affects the fdb or the fpm (change in build(), depends() fix,
+  etc) you should do so.

== How do I repair a corrupted package database?

-Restore a backup from the `/pub/other/fdb-snapshot` directory, and check what
-its version (the `.version` file in the tarball).
+Restore a backup from the `/pub/other/fdb-snapshot` directory, and check its
+version (the `.version` file in the tarball).

Then run:

diff --git a/docs/getting-involved.txt b/docs/getting-involved.txt
old mode 100644
new mode 100755
index 28a2a16..e923590
--- a/docs/getting-involved.txt
+++ b/docs/getting-involved.txt
@@ -3,9 +3,9 @@
== Ways of contributing

There are many different ways to contribute to Frugalware. You can write
-documentation, translate the existing ones to your native language (or
-any other language you want to) maintain packages or making them better
-whith adding features whatever.
+documentation, translate the existing documentation into your native language
+(or any other language you want to), maintain packages or improve them with
+added features etc.

If you are a programmer you can help us in developing our applications.
These are: pacman-g2, gfpm, fwlive, frugalwareutils, setup etc. See
@@ -13,7 +13,7 @@ http://git.frugalware.org[git.frugalware.org] for different 
project
repositories.

You can also start new projects. If you show some code we can surely host
-your project too if it's frugalware related. For example you want to write
+your project too if it's Frugalware related. For example you want to write
kfpm :)

IMPORTANT: After each title in brackets you can find the target audience.
@@ -25,15 +25,14 @@ documentation page.

=== Necessary documentation (packagers, coders)

-In the first part i will cover the necessary informations for those who
-do _not_ have developer status yet.
+In the first part I will cover the information necessary for those who do _not_
+have developer status yet.

In the second part we will set up the necessary config files.

-First of all, we ask you to read the following documentations carefully.
-If you do not want to deal with packages, just want to code it's usually
-enough to read the git documentation as we store our code in git
-repositories.
+First of all, we ask you to read the following documentation carefully. If you
+do not want to deal with packages, but just want to code it's usually enough to
+read  the git documentation as we store our code in git repositories.

* man makepkg
* man pacman-g2
@@ -43,10 +42,10 @@ repositories.
* http://frugalware.org/docs/makepkg[makepkg howto]
* http://www.kernel.org/pub/software/scm/git/docs/everyday.html[git getting 
started]

-I know, it is boring reading documentation, but you have to know that
-writing them is even worse so do not ask questions when there is the
-answer in the documentation. If you can not understand something
-feel free to join #[email protected] and ask.
+I know, it is boring reading documentation, but you have to know that writing
+it is even worse so do not ask questions when the answer in the documentation.
+If you can not understand something feel free to join
+#[email protected] and ask.

=== Downloading and setting up the repositories

@@ -77,7 +76,7 @@ Also you can use other mirrors as well.

==== Getting pacman-g2 and other code (coders)

-First of all you need the repo of the program. In this example i will use
+First of all you need the repo of the program. In this example I will use
pacman-g2, but the steps are very similar.
NOTE: Most of our programs need the translations repo to compile)

@@ -111,7 +110,7 @@ TIP: You can also use 'git diff .' (note the dot in the 
end). In
that case git will show the changes recursively in the current directory.
It is very handy when you have lot of uncommitted changes in your repo.

-If you satisfied with the changes run
+If you are satisfied with the changes run

--------------
$ git commit -a
@@ -131,12 +130,11 @@ or using native git commands:
$ git add -p; git commit
----

-Without committing your changes you can not send nor
-push (just developers) it.
+Without committing your changes you can not send nor push (just developers) it.

-TIP: With frugalware-* repos it's recommended to use 'repoman rec'
-which is a wrapper for dg record. It sets up the patch name properly
-so you only need to deal with the details.
+TIP: With frugalware-* repos it's recommended to use 'repoman rec' which is a
+wrapper for dg record. It sets up the patch name properly so you only need to
+deal with the details.

Here comes the final step. Send in the patch(es)!

@@ -162,8 +160,8 @@ NOTE: You have to subscribe to the
http://frugalware.org/mailman/listinfo/frugalware-devel[frugalware-devel]
mailing list and set up your SMTP server properly (if you use `git send-email`).

-Not really belongs to here but I want to document it somewhere. If you are a
-developer and want to apply such a patch, you need:
+It doesn't really belong to here but I want to document it somewhere. If you 
are
+a developer and want to apply such a patch, you need:

- Check the patch itself. If the second line is not an empty one, then you need
to hand-edit the patch before applying:
@@ -213,8 +211,8 @@ please try to respond.
frugalware-git mailing list. This is list has a big traffic since a
new mail is sent for each patch. If you don't have time to read it,
subscribe then set the "I would like to receive no mail" option.
-Also take care that your subscribing email equals to the one you set using `git
-config user.email`
+Also take care that your subscribing email address is the same one you set 
using
+`git config user.email`
* It's good if you can join the user and developer channel when you're
online.
* Maintain your packages. Try to resolve your assigned bugs, try to keep
@@ -223,8 +221,8 @@ online.
usually a bad sign. It's - of course - OK when you go for vacation a few
times a year, but then please announce it on the developer mailing list
so that we won't wait for you when fixing urgent problems, etc.
-* Document yourself. The documentation worth nothing if it's outdated.
-  Ideally one who never contacted us should be able to understand every
+* Document your work. The documentation is worth nothing if it's outdated.
+  Ideally somone who has never contacted us should be able to understand every
detail of Frugalware, just from documentation. No secrets! We are not
kids.
* If you have time, try to read the mailing lists ( `frugalware-use...@` )
@@ -271,9 +269,9 @@ your changes.
$ repoman push
--------------

-It will check the FrugalBuild using fblint, then records your changes,
-pushes them, uploads the fpms and finally creates the changelog, updates
-the fdb etc. So you are done if there was no error message.
+It will check the FrugalBuild using fblint, then record your changes, push 
them,
+upload the fpms and finally create the changelog, update the fdb etc. So you
+are done if there was no error message.

==== Setting up other repos (coders)

diff --git a/docs/gnome-bump-howto.txt b/docs/gnome-bump-howto.txt
old mode 100644
new mode 100755
index a77c1bd..4b857cc
--- a/docs/gnome-bump-howto.txt
+++ b/docs/gnome-bump-howto.txt
@@ -4,8 +4,9 @@ You *MUST* follow this HOWTO when bumping GNOME to a new 
version (even a minor
version).

To start, packages must be compiled in the order listed below (if you find a
-change that needs making to this list, poke AlexExtreme). If it is a major bump
-(2.14 to 2.16, for example), it is wise to rebuild most of the GNOME packages.
+change that needs to be made to this list, poke Bouleetbil). If it is a major
+bump (2.14 to 2.16, for example), it is wise to rebuild most of the GNOME
+packages.

== GNOME compile order

@@ -155,7 +156,7 @@ NOTE: all *sharp and all bindings need to be split

== Bumping individual packages

-Never, i repeat, *NEVER* bump a version without doing the following:
+Never, I repeat, *NEVER* bump a version without doing the following:

. Download the new version's tarball and extract it

@@ -167,7 +168,7 @@ devels about whether it is a good idea to use the optional 
dependencies.
FrugalBuild

. Check GConf schemas. Sometimes they have been renamed, or new ones have been
-added Not doing this can cause a lot of problems.
+added. Not doing this can cause a lot of problems.

. Check the Changelog and NEWS file for the package. Sometimes there may be
API/ABI changes that need to be considered before bumping.
diff --git a/docs/gpg.txt b/docs/gpg.txt
old mode 100644
new mode 100755
index 121b447..1a27952
--- a/docs/gpg.txt
+++ b/docs/gpg.txt
@@ -1,15 +1,13 @@
-= Checking if Frugalware tarballs are from trusted source
+= Checking if Frugalware tarballs are from a trusted source

== How to verify

-- Import our public keyring with the
+- Import our public keyring with the following command:

------------------------
$ gpg --recv-keys 20F55619
------------------------

-command.
-
- Verify the tarball. Here is an example:

------------------------------------------------------------------------------
@@ -23,4 +21,4 @@ gpg: Good signature from "Frugalware Linux Archives 
Verification Key \

This signature does not guarantee that the Frugalware Linux Archives master
site itself has not been compromised. However, if we suffer an intrusion we
-will revoke the key and post information here as quickly as possible.
+will revoke the key and post information on the home page as quickly as 
possible.
diff --git a/docs/introduction.txt b/docs/introduction.txt
old mode 100644
new mode 100755
index 3827cca..10d2445
--- a/docs/introduction.txt
+++ b/docs/introduction.txt
@@ -6,17 +6,17 @@ about how to read it.
== Things that you should really read

First there are some part of this document that you should really read, to
-understand how frugalware is working and how to administrate it.
+understand how Frugalware works and how to administer it.

.Important references to read:
* This introduction ;)
* How to use pacman-g2.
-* How to manage service.
+* How to manage services.

== Running console commands

-Along this document, there are boxed text that shows you a console log. These
-logs are important and requires quite some attentions since most off the time
+Throughout this document, there is boxed text which shows you console output.
+These are important and require quite some attention since most of the time
you are expected to run them and get the same output.

--------------
@@ -24,36 +24,38 @@ $ echo foo bar
foo bar
--------------

-This is how a console log look. Lets details it so you understand what means.
+This is how a console log look. Let's look at its details so you understand
+what it means.

-The `echo foo bar` part is what you should type and it's the command. The 
following line
-`foo bar` is the ouput of the previous command.
+The `echo foo bar` part is what you should type and it's the command. The
+following line `foo bar` is the output of the previous command.

-You may wonder what differenciate the command from the output. You see that in
+<<<>>>
+
+You may wonder what differentiates the command from the output. You see that in
front of the command there is a `$`. This indicates that it's a command line,
but there is more meaning in this symbol. This symbol can change depending
-on the user priviledges required to run the command.
+on the user privileges required to run the command.

.Here is the list of the common prefix for the console commands:
* `$` indicates that any user can run the command. Most of the time it means
-you have to run it with your user.
+you have to run it with your own user account.

-* `user$` indicates that a the specified user priviledge are required to run 
this
-command. Usually this is necessary for security reasons.
+* `user$` indicates that the specified user's privileges are required to run
+this command. Usually this is necessary for security reasons.
+
You can get an interactive shell for this user, replacing 'user' with the
-wanted user name, by issuing:
+desired user name, by issuing:
+
-----------
$ su - user
-----------

-* `#` indicates that the `root` users priviledges are required to run this 
command.
-Usually this is required to manage the system configuration.
+* `#` indicates that the `root` user's privileges are required to run this
+command. Usually this is required to manage the system configuration.
+
You can get an interactive shell for 'root' running:
+
------
-$ su -
+$ su -
------
-
diff --git a/docs/list-rules.txt b/docs/list-rules.txt
old mode 100644
new mode 100755
index 1a57167..28cc158
--- a/docs/list-rules.txt
+++ b/docs/list-rules.txt
@@ -2,7 +2,7 @@

== Introduction

-The purpose of this document is to define rules that helps the communication on
+The purpose of this document is to define rules that help the communication on
the mailing lists of Frugalware Linux.

== Mailing Lists
@@ -31,7 +31,7 @@ the mailing lists of Frugalware Linux.
(link:http://forums.frugalware.org/index.php?t=thread&frm_id=34[this forum])
and people who read the mailing lists only. The primary benefit is that not
all developers read the Forums, but mailing lists.
-* frugalware-users is for general user questions. It seems the Forums are much
+* frugalware-users is for general user questions. It seems the Forums are very
popular, but we still provide a mailing list for user questions.
* frugalware-users-hu is for Hungarian user questions.

@@ -58,9 +58,8 @@ In practice if this is a new situation for you, then use your 
mail client's
'list-reply' function, as the 'reply' function will send the mail off-list
which is not something you want in most cases.

-Also please do not use the 'group-reply' function if possible, users must
-subscribe before they post, so you can be sure about they are in the mailing
-list.
+Also please do not use the 'group-reply' function if possible. Users must
+subscribe before they post, so you can be sure they are in the mailing list.

(This is different to some other projects' rules. Some projects require you to
use 'group-reply' all the time, please do not do so on our lists.)
diff --git a/docs/make-translation-for-rc-scripts.txt 
b/docs/make-translation-for-rc-scripts.txt
old mode 100644
new mode 100755
index b67d493..262fe9d
--- a/docs/make-translation-for-rc-scripts.txt
+++ b/docs/make-translation-for-rc-scripts.txt
@@ -3,8 +3,7 @@ Marcus Habermehl <[email protected]>

== Preparing the source

-The first things to make a script translatable you must add this two lines to
-the rc script.
+To make a script translatable you must first add these two lines to the rc 
script.

---------------------------------------
TEXTDOMAIN=my_service
diff --git a/docs/mobile.txt b/docs/mobile.txt
old mode 100644
new mode 100755
index ba7a2cd..dc162e4
--- a/docs/mobile.txt
+++ b/docs/mobile.txt
@@ -2,13 +2,13 @@

== Battery, buttons, thermal management

-Notebook users are usually interested in the state of their battery.
-To get the power button and the lid's sensor of its closed state emit
-events is also nice. Some notebooks only shut down their continously
-running fans and operate only if needed if the thermal module is loaded.
+Notebook users are usually interested in the state of their battery. To get the
+power button and the lid's sensor of its closed state to emit events is also
+nice. Some notebooks only shut down their continously running fans and operate
+only if needed if the thermal module is loaded.

Usually the following steps are required to enable this functionality:
-Adding the following lines to '/etc/sysconfig/modules' to get modules
+Adding the following lines to '/etc/sysconfig/modules' to get modules
loaded at system startup:

-------
@@ -41,24 +41,23 @@ The only remaining task is to start a client: if you're on 
console, try the

== Conserving power

-The major consumers of power in a notebook are the LCD (size and brightness
-level), the CPU, hard drives, wireless transceivers like WiFi, Bluetooth,
+The major consumers of power in a notebook are the LCD (size and brightness
+level), the CPU, hard drives, wireless transceivers like WiFi, Bluetooth,
Infrared and the GPU if you have a powerful one.

You can conserve a fair amount of power if you lessen the brightness level
of the LCD screen. Some notebooks can remember two settings of this level,
-one when the equipment operates from battery and for another when powered
-from AC.
+one when the equipment operates from battery and another when powered from AC.

-The CPUs have some sort of power saving capabilities, the most basic is
-"CPU throttling". Common on Intel mobile Celeron CPUs, only ACPI is
+The CPUs have some sort of power saving capabilities, the most basic is
+"CPU throttling". Common on Intel mobile Celeron CPUs, only ACPI is
needed. Klaptop has a setting for it, where you can specify the level.

//FIXME governors, Intel Centrino/Core, AMD

Letting the HDD spin down gives little extra battery operating time, but
-frequent spinups (data access) and spindowns wears the disk. Only useful
-in situations where there is no frequent need for data on hdd like holding
+frequent spinups (data access) and spindowns wears the disk. Only useful
+in situations where there is no frequent need for data on hdd like holding
a presentation.

== Hibernation
@@ -109,5 +108,6 @@ After the above are done, you must reboot. The hibernation 
can be started with:
`echo shutdown > /sys/power/disk; echo disk > /sys/power/state`

and next time you boot your kernel it should resume. For more info, look at
-'/usr/src/linux/Documentation/power/swsusp.txt'.  It requires the kernel 
documentation,
-which can be installed issuing the `pacman-g2 -S kernel-docs` command as root.
+'/usr/src/linux/Documentation/power/swsusp.txt'.  It requires the kernel
+documentation, which can be installed issuing the `pacman-g2 -S kernel-docs`
+command as root.
diff --git a/docs/pacman-g2.txt b/docs/pacman-g2.txt
old mode 100644
new mode 100755
diff --git a/docs/repos.txt b/docs/repos.txt
old mode 100644
new mode 100755
index 89b7ad4..06220c5
--- a/docs/repos.txt
+++ b/docs/repos.txt
@@ -7,31 +7,29 @@ Frugalware FTP Server and on the Frugalware Gitweb Interface.

== Location of the repository

-Since a repository consists of plain files, we can and should place them on 
the ftp
-server (/pub). To prevent further problems, always use the server name
+Since a repository consists of plain files, we can and should place them on the
+ftp server (/home/ftp). To prevent further problems, always use the server name
"git.frugalware.org", currently it's an alias of genesis.frugalware.org.

First decide if it's a personal repository or a team one. For example if you
-create a repository to update to a newer python version, then probably you will
-do all the work, create it under `/pub/other/people/nick/reponame`.
+create a repository to update to a newer python version, then you will
+probably do all the work, create it under `/pub/other/people/nick/reponame`.
+Simply create a dir, issue `git init` and push at least one commit to there.

-The steps are:
+If you want to allow others to push to your repo, then you want to allow them
+to lock your repo. This requires

-. Create a dir
-
-. Issue `git init` and `git config receive.denycurrentbranch ignore`.
-
-. Push at least one commit to there.
-
-. Enable the required hooks (see below).
+----
+chmod g+w .git
+----

Now anyone can `git clone` it, using a 'full mirror', for example
-`http://www12.frugalware.org/mirrors/ftp.frugalware.org/pub/`.
+`ftp://ftp12.frugalware.org/mirrors/ftp.frugalware.org/pub/`.

== Registering for the gitweb interface

If the repository is a team one, then create it under /pub/other. In this case
-probably you want the gitweb interface, too. To use it:
+you probably want the gitweb interface, too. To use it:

. Update the file `.git/description` inside the repo with a short (less than 80
chars) description.
@@ -53,11 +51,11 @@ be updated automatically, you need a hook to do so.

. If you want CIA notification.

-. If you want sending mails to the `Frugalware-git` mailing list.
+. If you want to send mails to the `Frugalware-git` mailing list.

-. If you want to let other be able to clone your repository via 'dumb'
-protocols like `http` or `rsync`. (This means that if you disable this hook, it
-won't be accessible anonymously!)
+. If you want to let others clone your repository via 'dumb' protocols like
+  `http` or `rsync`. (This means that if you disable this hook, it won't be
+  accessible anonymously!)

For the last one:

@@ -68,5 +66,5 @@ chmod +x .git/hooks/post-update
For the others:

----
-ln -sf /pub/other/git-hooks/git-hooks.py .git/hooks/post-receive
+ln -sf /home/ftp/pub/other/git-hooks/git-hooks.py .git/hooks/post-receive
----
diff --git a/docs/testsuite.txt b/docs/testsuite.txt
old mode 100644
new mode 100755
index 93ae17c..6348131
--- a/docs/testsuite.txt
+++ b/docs/testsuite.txt
@@ -3,7 +3,7 @@
== Introduction

The testsuite is a set of several simple unit tests. Most of the tests were
-written when a typo has been found, so that we hope next time it'll be detected
+written when a typo was been found, so that we hope next time it'll be detected
automatically. When a problem was found, a test was created and the test
failed. After the problem was fixed the test passed. The statistics section
contains special tests: we are aware that they do not pass, but their actual
@@ -23,7 +23,7 @@ Basically there are 3 simple rules for these tests:

- If the first argument is `--help`, they should print a short (less than 80
chars) description. This will be displayed if the test fails as sometimes the
-name of the test may not be self-expressing.
+name of the test may not be descriptive enough.

- The tests are called in a `./testname` form, without any argument. This
allows you to use various interpreted programming languages (python, bash,
_______________________________________________
Frugalware-git mailing list
[email protected]
http://frugalware.org/mailman/listinfo/frugalware-git

Reply via email to