← Back to team overview

ubuntu-packaging-guide-team team mailing list archive

[Merge] lp:~mitya57/ubuntu-packaging-guide/misc-fixes into lp:ubuntu-packaging-guide

 

Dmitry Shachnev has proposed merging lp:~mitya57/ubuntu-packaging-guide/misc-fixes into lp:ubuntu-packaging-guide.

Requested reviews:
  Ubuntu Packaging Guide Team (ubuntu-packaging-guide-team)

For more details, see:
https://code.launchpad.net/~mitya57/ubuntu-packaging-guide/misc-fixes/+merge/130514

Continuing spamming Daniel with merge proposals, this time lots of small content fixes :)
-- 
https://code.launchpad.net/~mitya57/ubuntu-packaging-guide/misc-fixes/+merge/130514
Your team Ubuntu Packaging Guide Team is requested to review the proposed merge of lp:~mitya57/ubuntu-packaging-guide/misc-fixes into lp:ubuntu-packaging-guide.
=== modified file 'themes/ubuntu/static/base.css'
--- themes/ubuntu/static/base.css	2012-10-16 12:17:06 +0000
+++ themes/ubuntu/static/base.css	2012-10-19 10:03:54 +0000
@@ -36,6 +36,7 @@
 code,
 div.highlight-makefile,
 div.highlight-sh,
+div.highlight-diff,
 div.highlight-python {
 	padding: 10px;
 	font-family: 'Ubuntu Mono', 'Consolas', 'Monaco', 'DejaVu Sans Mono', Courier, monospace;

=== modified file 'ubuntu-packaging-guide/chroots.rst'
--- ubuntu-packaging-guide/chroots.rst	2012-03-20 22:02:49 +0000
+++ ubuntu-packaging-guide/chroots.rst	2012-10-19 10:03:54 +0000
@@ -31,7 +31,7 @@
 main system.
 
 You might want to copy your GPG/ssh keys and Bazaar configuration into the
-chroot so you can access and sign packages directly.
+chroot so you can access and sign packages directly::
 
     $ sudo mkdir oneiric/home/<username>
     $ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar oneiric/home/<username>
@@ -62,7 +62,7 @@
 
 You can also set up pbuilder to pause when it comes across a build
 failure.  Copy C10shell from /usr/share/doc/pbuilder/examples into a
-directory and use the --hookdir= argument to point to it.
+directory and use the ``--hookdir=`` argument to point to it.
 
 Amazon's `EC2 cloud computers`_ allow you to hire a computer paying a
 few US cents per hour, you can set up Ubuntu machines of any supported

=== modified file 'ubuntu-packaging-guide/debian-dir-overview.rst'
--- ubuntu-packaging-guide/debian-dir-overview.rst	2012-07-23 14:52:17 +0000
+++ ubuntu-packaging-guide/debian-dir-overview.rst	2012-10-19 10:03:54 +0000
@@ -190,7 +190,9 @@
 again.
 
 Here is a simplified version of the rules file created by ``dh_make`` (which 
-can be found in the ``dh-make`` package)::
+can be found in the ``dh-make`` package):
+
+.. code-block:: makefile
 
  #!/usr/bin/make -f
  # -*- makefile -*-

=== modified file 'ubuntu-packaging-guide/fixing-a-bug-example.rst'
--- ubuntu-packaging-guide/fixing-a-bug-example.rst	2012-10-17 22:00:23 +0000
+++ ubuntu-packaging-guide/fixing-a-bug-example.rst	2012-10-19 10:03:54 +0000
@@ -130,7 +130,9 @@
 
         bzr diff
 
-you should see something like this:: 
+you should see something like this:
+
+.. code-block:: diff
 
 	=== modified file 'debian/control'
 	--- debian/control	2012-05-14 23:38:14 +0000
@@ -165,7 +167,9 @@
 
         bzr diff debian/changelog 
 
-and you will see something like this:: 
+and you will see something like this:
+
+.. code-block:: diff
 
         === modified file 'debian/changelog'
 	--- debian/changelog	2012-05-14 23:38:14 +0000

=== modified file 'ubuntu-packaging-guide/getting-set-up.rst'
--- ubuntu-packaging-guide/getting-set-up.rst	2012-08-28 23:27:17 +0000
+++ ubuntu-packaging-guide/getting-set-up.rst	2012-10-19 10:03:54 +0000
@@ -281,8 +281,8 @@
 as well. Simply open your `~/.bashrc` in a text editor and add something like
 this to the bottom of it::
 
-    $ export DEBFULLNAME="Bob Dobbs"
-    $ export DEBEMAIL="subgenius@xxxxxxxxxxx"
+    export DEBFULLNAME="Bob Dobbs"
+    export DEBEMAIL="subgenius@xxxxxxxxxxx"
 
 Now save the file and either restart your terminal or run::
 

=== modified file 'ubuntu-packaging-guide/kde.rst'
--- ubuntu-packaging-guide/kde.rst	2012-03-20 22:02:49 +0000
+++ ubuntu-packaging-guide/kde.rst	2012-10-19 10:03:54 +0000
@@ -4,7 +4,7 @@
 
 Packaging of KDE programs in Ubuntu is managed by the Kubuntu and
 MOTU teams.  You can contact the Kubuntu team on the `Kubuntu mailing
-list`_ and ``#kubuntu-devel`` Freenode IRC channl.  More information
+list`_ and ``#kubuntu-devel`` Freenode IRC channel.  More information
 about Kubuntu development is on the `Kubuntu wiki page`_.
 
 Our packaging follows the practices of the ``Debian Qt/KDE Team`` and

=== modified file 'ubuntu-packaging-guide/libraries.rst'
--- ubuntu-packaging-guide/libraries.rst	2012-09-17 08:10:40 +0000
+++ ubuntu-packaging-guide/libraries.rst	2012-10-19 10:03:54 +0000
@@ -38,7 +38,7 @@
     $ bzr branch ubuntu:natty/libnova
     $ sudo apt-get install libnova-dev
 
-To find the SONAME of the library run
+To find the SONAME of the library run::
 
     $ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME
 

=== modified file 'ubuntu-packaging-guide/packaging-new-software.rst'
--- ubuntu-packaging-guide/packaging-new-software.rst	2012-09-17 08:24:04 +0000
+++ ubuntu-packaging-guide/packaging-new-software.rst	2012-10-19 10:03:54 +0000
@@ -61,7 +61,7 @@
 
 ``bzr-builddeb`` includes a plugin to create a new package from a template. The
 plugin is a wrapper around the ``dh_make`` command. You should already have
-these if you installed ``packaging-dev`` Run the command providing the package
+these if you installed ``packaging-dev``. Run the command providing the package
 name, version number, and path to the upstream tarball::
 
     $ sudo apt-get install dh-make
@@ -218,7 +218,7 @@
     section documents processes for submitting new packages.
 
 In some cases, it might make sense to go directly into Ubuntu first. For
-instance, Debian might be in a freeze making it unlikely that you're
+instance, Debian might be in a freeze making it unlikely that your
 package will make it into Ubuntu in time for the next release. This
 process is documented on the `"New Packages" section of the Ubuntu wiki`_.
 

=== modified file 'ubuntu-packaging-guide/patches-to-packages.rst'
--- ubuntu-packaging-guide/patches-to-packages.rst	2012-03-20 22:02:49 +0000
+++ ubuntu-packaging-guide/patches-to-packages.rst	2012-10-19 10:03:54 +0000
@@ -108,12 +108,12 @@
 might need to be removed altogether.
 
 You should start by ensuring no patches are applied.  Unfortunately a commit is
-needed before you can merge in the new upstream (this is `bug 815854`_::
+needed before you can merge in the new upstream (this is `bug 815854`_)::
 
     $ quilt pop -a
     $ bzr commit -m "remove patches"
 
-Then upgrade to the new version
+Then upgrade to the new version::
 
     $ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2
 
@@ -168,8 +168,8 @@
 You can use ``edit-patch``, shown in previous chapters, as a reliable way to
 work with all systems.
 
-Even older packages will include changes directly to sources and kept in the
-``diff.gz`` source file.  This makes it hard to upgrade to new upstream
+In even older packages changes will be included directly to sources and kept
+in the ``diff.gz`` source file.  This makes it hard to upgrade to new upstream
 versions or differentiate between patches and is best avoided.
 
 Bazaar Loom is a way to keep patches as part of bzr trees, see :doc:`Working

=== modified file 'ubuntu-packaging-guide/udd-working.rst'
--- ubuntu-packaging-guide/udd-working.rst	2012-02-29 10:05:20 +0000
+++ ubuntu-packaging-guide/udd-working.rst	2012-10-19 10:03:54 +0000
@@ -28,11 +28,11 @@
     $ bzr branch tomboy.dev bug-12345
     $ cd bug-12345
 
-Now you can do all my work in the `bug-12345` directory.  You make changes
+Now you can do all my work in the ``bug-12345`` directory.  You make changes
 there as necessary, committing as you go along.  This is just like doing any
 kind of software development with Bazaar.  You can make intermediate commits
 as often as you like, and when your changes are finished, you will use the
-standard `dch` command (from the `devscripts` package)::
+standard ``dch`` command (from the ``devscripts`` package)::
 
     $ dch -i
 
@@ -41,11 +41,11 @@
 
 .. _link-via-changelog:
 
-When you added your `debian/changelog` entry, you should have included a bug
+When you added your ``debian/changelog`` entry, you should have included a bug
 fix tag that indicated which Launchpad bug issue you're fixing.  The format of
 this textual tag is pretty strict: ``LP: #12345``.  The space between the
 ``:`` and the ``#`` is required and of course you should use the actual bug
-number that you're fixing.  Your `debian/changelog` entry might look something
+number that you're fixing.  Your ``debian/changelog`` entry might look something
 like::
 
     tomboy (1.5.2-1ubuntu5) natty; urgency=low
@@ -62,7 +62,7 @@
 message and set the tag to mark bug #12345 as fixed.
 
 This only works with bzr-builddeb 2.7.5 and bzr 2.4, for older versions use
-`debcommit`.
+``debcommit``.
 
 
 Building the package
@@ -71,13 +71,13 @@
 Along the way, you'll want to build your branch so that you can test it to
 make sure it does actually fix the bug.
 
-In order to build the package you can use the `bzr builddeb` command from
-the `bzr-builddeb` package.  You can build a source package with::
+In order to build the package you can use the ``bzr builddeb`` command from
+the ``bzr-builddeb`` package.  You can build a source package with::
 
     $ bzr builddeb -S
 
-(`bd` is an alias for `builddeb`.)  You can leave the package unsigned by
-appending `-- -uc -us` to the command.
+(``bd`` is an alias for ``builddeb``.)  You can leave the package unsigned by
+appending ``-- -uc -us`` to the command.
 
 It is also possible to use your normal tools, as long as they are able to
 strip the .bzr directories from the package, e.g.::
@@ -85,11 +85,11 @@
     $ debuild -i -I
 
 If you ever see an error related to trying to build a native package without a
-tarball, check to see if there is a `.bzr-builddeb/default.conf` file
+tarball, check to see if there is a ``.bzr-builddeb/default.conf`` file
 erroneously specifying the package as native.  If the changelog version has a
 dash in it, then it's not a native package, so remove the configuration file.
-Note that while `bzr builddeb` has a `--native` switch, it does not have a
-`--no-native` switch.
+Note that while ``bzr builddeb`` has a ``--native`` switch, it does not have a
+``--no-native`` switch.
 
 Once you've got the source package, you can build it as normal with
 ``pbuilder-dist`` (or ``pbuilder`` or `sbuild`_).


Follow ups