fix validation

Original commit message from CVS:
fix validation
parent 2ced1a34
common @ 79e6940e
Subproject commit 773e3a64961084c37477faa464f12add3dfcd6dc
Subproject commit 79e6940e7ff1a6cbf959a1f7a0a3d1ed3f90d3ee
......@@ -35,3 +35,7 @@ www-faq: gstreamer-faq
perl -i -p -e's@href="index\.html@href="index.php@' $$a; \
perl -i -p -e's@href="(ar.*)\.html@href="$$1.php@' $$a; \
done
check:
xmllint -noout -valid $(MAIN)
......@@ -30,15 +30,16 @@ prefix both aclocal and libtool are installed.
<para>
You can do three things to fix this :
<orderedlist>
<listitem>install automake in the same prefix as libtool</listitem>
<listitem>force use of the automake installed in the same prefix as libtool
by using the --with-automake option</listitem>
<listitem>figure out what prefix libtool has been installed to and point
aclocal to the right location by running</listitem>
<listitem><para>install automake in the same prefix as libtool</para></listitem>
<listitem><para>force use of the automake installed in the same prefix as libtool
by using the --with-automake option</para></listitem>
<listitem><para>figure out what prefix libtool has been installed to and point
aclocal to the right location by running
<programlisting>
export ACLOCAL_FLAGS="-I $(prefix)/share/aclocal"
</programlisting>
where you replace prefix with the prefix where libtool was installed.
</para></listitem>
</orderedlist>
</para>
</answer>
......
<sect1 id="chapter-developing">
<title id="title-developing">Developing applications with GStreamer</title>
<qandaset defaultlabel="qandaset-developing">
<qandaset>
<qandaentry>
<question id="developing-compile-programs">
......
......@@ -30,17 +30,17 @@ Why is GStreamer written in C ? Why not C++/Objective-C/... ?
We like C. Aside from "personal preference", there are a number of technical
reasons why C is nice in this project:
<itemizedlist>
<listitem>C is extremely portable.</listitem>
<listitem>C is fast.</listitem>
<listitem>It is easy to make language bindings for libraries written in C.
</listitem>
<listitem>The GObject object system provided by GLib implements objects in C,
<listitem><para>C is extremely portable.</para></listitem>
<listitem><para>C is fast.</para></listitem>
<listitem><para>It is easy to make language bindings for libraries written in C.
</para></listitem>
<listitem><para>The GObject object system provided by GLib implements objects in C,
in a portable, powerful way. This library provides for introspection and
runtime dynamic typing. It is a full OO system, but without the syntactic
sugar. If you want sugar, take a look at
<ulink url="http://www.5z.com/jirka/gob.html">GOB</ulink>.</listitem>
<listitem>Use of C integrates nicely with Gtk+ and GNOME. Some people like
this a lot, but neither Gtk+ nor GNOME are required by GStreamer.</listitem>
<ulink url="http://www.5z.com/jirka/gob.html">GOB</ulink>.</para></listitem>
<listitem><para>Use of C integrates nicely with Gtk+ and GNOME. Some people like
this a lot, but neither Gtk+ nor GNOME are required by GStreamer.</para></listitem>
</itemizedlist>
</para>
<para>
......@@ -88,10 +88,10 @@ terms of the libraries we use. As a general rule, GStreamer aims at using
only LGPL or BSD licensed libraries if available and only use GPL or
proprietary libraries where no good LGPL or BSD alternatives are available.
</para>
<para>
From GStreamer 0.4.2 on, we implemented a license field for all of the plugins,
and in the future we might have the application enforce a stricter policy
(much like tainting in the kernel).
<para>
</para>
</answer>
</qandaentry>
......
......@@ -11,12 +11,12 @@
<para>
Generally speaking, you have three options, ranging from easy to hard :
<itemizedlist>
<item><link linkend="getting-gstreamer-packages">
distribution-specific packages</link></item>
<item><link linkend="getting-gstreamer-source">
source tarballs</link></item>
<item><link linkend="getting-gstreamer-packages">
CVS</link></item>
<listitem><para><link linkend="getting-gstreamer-packages">
distribution-specific packages</link></para></listitem>
<listitem><para><link linkend="getting-gstreamer-source">
source tarballs</link></para></listitem>
<listitem><para><link linkend="getting-gstreamer-packages">
CVS</link></para></listitem>
</itemizedlist>
</para>
</answer>
......
......@@ -3,18 +3,25 @@
<para>
So you're eager to get started learning about GStreamer.
There's a few ways you can get started.
<itemizedlist>
<listitem>If you want to learn by reading about it, start with
<xref linkend="title-general" endterm="title-general"/></listitem>
<listitem>
<itemizedlist>
<listitem>
<para>
If you want to learn by reading about it, start with
<xref linkend="title-general" endterm="title-general"/>
</para>
</listitem>
<listitem>
<para>
If you'd rather learn by trying it out, start with
<xref linkend="title-getting" endterm="title-getting"/>
</listitem>
<listitem>
</para>
</listitem>
<listitem>
<para>
If you want to live on the bleeding edge and develop and use CVS, see
<xref linkend="title-cvs" endterm="title-cvs"/>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
......@@ -24,11 +24,11 @@ If you're not sure either way, then chances are good that you don't have
it. You should get the plug-in and run gst-register to register it.
How to get the plug-in depends on your distribution.
<itemizedlist>
<listitem>if you run GStreamer using packages for your distribution, you
<listitem><para>if you run GStreamer using packages for your distribution, you
should check what packages are available for your distribution and see
if any of the available packages contains the plug-in.
</listitem>
<listitem>if you run GStreamer from a source install, there's a good chance
</para></listitem>
<listitem><para>if you run GStreamer from a source install, there's a good chance
the plug-in didn't get built because you are missing an external library.
When you ran configure, you should have gotten output of what plug-ins are
going to be built. You can re-run configure to see if it's there.
......@@ -37,13 +37,13 @@ The most likely is that you're missing the library you need for it.
Check the README file in gst-plugins to see what library you need.
Make sure to remember to re-run configure after installing the supporting
library !
</listitem>
<listitem>
</para></listitem>
<listitem><para>
if you run GStreamer from CVS, the same logic applies as for a source install.
Go over the reasons why the plug-in didn't get configured for build.
Check output of config.log for a clue as to why it doesn't get built if
you're sure you have the library needed installed in a sane place.
</listitem>
</para></listitem>
</itemizedlist>
</para>
......@@ -87,31 +87,31 @@ The second thing you can do is look at the backtrace to get an idea of where
things are going wrong, or give us an idea of what is going wrong.
To provide a backtrace, you should
<orderedlist>
<listitem>
<listitem><para>
run the application in gdb by starting it with
<programlisting>
gdb (gst-application)
</programlisting>
(If the application is in a source tree instead of installed on the system,
you might want to put "libtool" before "gdb")
</listitem>
<listitem>
</para></listitem>
<listitem><para>
Pass on the command line arguments to the application by typing
<programlisting>
set args (the arguments to the application)
</programlisting>
at the (gdb) prompt
</listitem>
<listitem>
</para></listitem>
<listitem><para>
Type "run" at the (gdb) prompt and wait for the application to
segfault. The application will run a lot slower, however.
</listitem>
<listitem>
</para></listitem>
<listitem><para>
After the segfault, type "bt" to get a backtrace. This is a stack of
function calls detailing the path from main () to where the code is
currently at.
</listitem>
<listitem>
</para></listitem>
<listitem><para>
If the application you're trying to debug contains threads, it is also
useful to do
<programlisting>
......@@ -120,14 +120,12 @@ To provide a backtrace, you should
and get backtraces of all of the threads involved, by switching to
a different thread using "thread (number)" and then again requesting
a backtrace using "bt".
</listitem>
<listitem>
<para>
</para></listitem>
<listitem><para>
If you can't or don't want to work out the problem yourself, a copy and paste
of all this information should be included in your
<link linkend="using-bugs-where">bug report</link>.
</para>
</listitem>
</para></listitem>
</orderedlist>
</para>
</answer>
......
......@@ -56,11 +56,11 @@ You can test this by trying to play a sine tone. For this, you need to
connect the sinesrc plug-in to an output plug-in that matches your hardware.
A (non-complete) list of output plug-ins for audio is
<itemizedlist>
<listitem>osssink for OSS output</listitem>
<listitem>esdsink for ESound output</listitem>
<listitem>artssink for aRTs output</listitem>
<listitem>alsasink for ALSA output</listitem>
<listitem>jacksink for JACK output</listitem>
<listitem><para>osssink for OSS output</para></listitem>
<listitem><para>esdsink for ESound output</para></listitem>
<listitem><para>artssink for aRTs output</para></listitem>
<listitem><para>alsasink for ALSA output</para></listitem>
<listitem><para>jacksink for JACK output</para></listitem>
</itemizedlist>
First of all, run gst-inspect on the output plug-in you want to use to
make sure you have it installed. For example, if you use OSS, run
......@@ -136,10 +136,10 @@ information, as we will most likely have to.
<para>
When doing a bug report, you should at least describe
<itemizedlist>
<listitem>your distribution</listitem>
<listitem>
how you installed GStreamer (from cvs, source, packages, which ?)</listitem>
<listitem>if you installed GStreamer before</listitem>
<listitem><para>your distribution</para></listitem>
<listitem><para>
how you installed GStreamer (from cvs, source, packages, which ?)</para></listitem>
<listitem><para>if you installed GStreamer before</para></listitem>
</itemizedlist>
</para>
<para>
......
Markdown is supported
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