Commit 5304d214 authored by Stefan Weil's avatar Stefan Weil
Browse files

Fix typos (found by codespell)



Signed-off-by: Stefan Weil's avatarStefan Weil <sw@weilnetz.de>
parent be710a35
......@@ -110,7 +110,7 @@ Changes in O.5.4
- Correct the version strings. (John Ralls)
- Restore inadvertently-deleted run-install-name-tool tag to bundle files. (John Ralls)
- Fix translation loop (John Ralls)
- More descriptive error message for unkown file copying errors (John Ralls)
- More descriptive error message for unknown file copying errors (John Ralls)
- Add an example pygtk bundle (John Ralls)
- Write Package type into PkgInfo. (John Ralls)
- Provide a (normally commented out) block which reports each binary file processed so that one can find out which error messages go with which file. (John Ralls)
......
......@@ -76,7 +76,7 @@ The simple example above works for small and simple applications, but
often you will need to specify more data to copy in, or to have more
detailed control over what is copied.
Here we go through in more depth how this can be acheived. Every file
Here we go through in more depth how this can be achieved. Every file
and directory to copy is specified with a source path, and an optional
destination path. An example that copies an entire directory
recursively, from the installation prefix:
......@@ -174,7 +174,7 @@ The launcher script is used to setup the necessary environment for the
application to work. If your application does this itself, you can
leave it out. Many applications will work out of the box with the
launcher script though. If no script is specified in the tag, a
default one is used, that sets up the needed environent for most GTK+
default one is used, that sets up the needed environment for most GTK+
applications.
Unsurprisingly, the main-binary tag specifies the executable to launch
......@@ -217,7 +217,7 @@ in the last path component, for example:
${prefix}/lib/gtk/2.10.0/loaders/*.so
</binary>
An intereseting twist is that some libraries that are built as dylibs
An interesting twist is that some libraries that are built as dylibs
are used as loadable modules. Dlopen doesn't have a problem with this,
it will cheerfully open either. The problem comes because unlike
Linux, Mac OS X uses different file extensions and formats, so libtool
......
......@@ -100,7 +100,7 @@ elif test -z $LANG -a -f "$I18NDIR/${APPLELOCALE:0:2}/LC_MESSAGES/$APP.mo"; then
export LANG="${APPLELOCALE:0:2}"
fi
#Next we need to set LC_MESSAGES. If at all possilbe, we want a full
#Next we need to set LC_MESSAGES. If at all possible, we want a full
#5-character locale to avoid the "Locale not supported by C library"
#warning from Gtk -- even though Gtk will translate with a
#two-character code.
......
......@@ -100,7 +100,7 @@ elif test -z $LANG -a -f "$I18NDIR/${APPLELOCALE:0:2}/LC_MESSAGES/$APP.mo"; then
export LANG="${APPLELOCALE:0:2}"
fi
#Next we need to set LC_MESSAGES. If at all possilbe, we want a full
#Next we need to set LC_MESSAGES. If at all possible, we want a full
#5-character locale to avoid the "Locale not supported by C library"
#warning from Gtk -- even though Gtk will translate with a
#two-character code.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment