Merge lp:~andrewsomething/ubuntu-packaging-guide/i18n into lp:ubuntu-packaging-guide

[Andrew Starr-Bochicchio]

[lp:~andrewsomething/ubuntu-packaging-guide/i18n]

98. By Andrew Starr-Bochicchio on 2012-03-16

Fix typo in latexpdf target.

99. By Andrew Starr-Bochicchio on 2012-03-16

Process html with sed to move them out of the redundant ubuntu-packaging-guide dir.

100. By Andrew Starr-Bochicchio on 2012-03-16

Also move single html out of redundant dir.

101. By Andrew Starr-Bochicchio on 2012-03-16

Adjust docbase files for new layout.

[Daniel Holbach (dholbach)]

Thanks a lot for your work on this. This is a great start.

We seem to have a new directory structure like

  /usr/share/doc/ubuntu-packaging-guide/html/en/packaging-new-software.html

now. It looks like we will just have to live with it (Updated bookmarks, etc.)

Also did I notice
  /usr/share/doc/ubuntu-packaging-guide/html/en/_static/minus.png
which looks like we'll have lots of duplicate files. I can't quite remember which technology we used to replace it with symlinks.

What are your thoughts on the above?

review: Needs Information

[Andrew Starr-Bochicchio (andrewsomething)]

On Fri, Mar 16, 2012 at 12:39 PM, Daniel Holbach
<email address hidden> wrote:
> Review: Needs Information
>
> Thanks a lot for your work on this. This is a great start.
>
> We seem to have a new directory structure like
>
>  /usr/share/doc/ubuntu-packaging-guide/html/en/packaging-new-software.html
>
> now. It looks like we will just have to live with it (Updated bookmarks, etc.)

I like keeping the orderly structure of:

 /usr/share/doc/ubuntu-packaging-guide/html/$lang/

But I guess there's no reason we can't put the English version
directly in html/ and just use html/$lang/ for other languages. I'll
push a new revision.

> Also did I notice
>  /usr/share/doc/ubuntu-packaging-guide/html/en/_static/minus.png
> which looks like we'll have lots of duplicate files. I can't quite remember which technology we used to replace it with symlinks.

There's probably a few ways we can do this. Since we're already
processing stuff with sed, maybe we could just make the links in the
html to html/$lang/_static/ all point to html/_static and share the
folder rather than symlinking?

-- Andrew Starr-Bochicchio

   Ubuntu Developer <https://launchpad.net/~andrewsomething>
   Debian Maintainer
<http://qa.debian.org/developer.php?login=a.starr.b%40gmail.com>
   PGP/GPG Key ID: D53FDCB1

[lp:~andrewsomething/ubuntu-packaging-guide/i18n]

102. By Andrew Starr-Bochicchio on 2012-03-16

Keep en version directly in html/ so we don't break links.

[Daniel Holbach (dholbach)]

Maybe it'd make sense to use something like fdupes for detecting duplicates? If we dig a little bit in debian/rules snippets I'm sure we ca find it somewhere? :)

[lp:~andrewsomething/ubuntu-packaging-guide/i18n]

103. By Andrew Starr-Bochicchio on 2012-03-19

Use fdupes to find and link identical resources.

[Andrew Starr-Bochicchio (andrewsomething)]

I think I've got it...

[Daniel Holbach (dholbach)]

I just pushed some changes to lp:~dholbach/ubuntu-packaging-guide/i18n which I think would be nice to have.

Personally I feel all versions of the /en/ flavour should live in ./ so we don't break links.

I also added a stub for the German translation, so we can mess around with it and test things.

The doc team had bits in their package build system at some stage which only made them include translations above a certain percentage of completion. Adding something along those lines might be interesting at some stage. We can file a separate bug about that.

Thanks a lot for your tireless work - I think with the changes above we're ready to go.

[lp:~andrewsomething/ubuntu-packaging-guide/i18n]

104. By Andrew Starr-Bochicchio on 2012-03-20

Merge lp:~dholbach/ubuntu-packaging-guide/i18n

[Andrew Starr-Bochicchio (andrewsomething)]

On Tue, Mar 20, 2012 at 12:26 PM, Daniel Holbach
<email address hidden> wrote:
> I just pushed some changes to lp:~dholbach/ubuntu-packaging-guide/i18n which I think would be nice to have.
>
> Personally I feel all versions of the /en/ flavour should live in ./ so we don't break links.
>
> I also added a stub for the German translation, so we can mess around with it and test things.

That makes sense. Merged

>
> The doc team had bits in their package build system at some stage which only made them include translations above a certain percentage of completion. Adding something along those lines might be interesting at some stage. We can file a separate bug about that.

Sounds like something we'd want. I'll look into that.

> Thanks a lot for your tireless work - I think with the changes above we're ready to go.

No problem at all. If you want, I can set up things on the Rosetta
end, but I'll need to be a project admin.

[Daniel Holbach (dholbach)]

Thanks again for your hard work on this!

review: Approve

[Daniel Holbach (dholbach)]

Hum, I'm not quite sure how I can make you a project admin.

[Andrew Starr-Bochicchio (andrewsomething)]

On Tue, Mar 20, 2012 at 6:02 PM, Daniel Holbach
<email address hidden> wrote:
> Hum, I'm not quite sure how I can make you a project admin.

Never mind that. I forgot that ~ubuntu-dev members are already
~ubuntu-packaging-guide-team members, so I already have the
permissions I need to do it.

=== modified file '.bzrignore'
--- .bzrignore	2010-11-17 14:39:13 +0000
+++ .bzrignore	2012-03-20 20:48:20 +0000
@@ -1,1 +1,4 @@
 _build
+po/*
+!po/*.pot
+!po/*.po

=== modified file 'Makefile'
--- Makefile	2010-11-17 14:00:59 +0000
+++ Makefile	2012-03-20 20:48:20 +0000
@@ -11,8 +11,12 @@
 PAPEROPT_a4     = -D latex_paper_size=a4
 PAPEROPT_letter = -D latex_paper_size=letter
 ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+PODIR         = po
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+LANGS = $(basename $(notdir $(wildcard $(PODIR)/*.po)))
 
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext locale
 
 help:
 	@echo "Please use \`make <target>' where <target> is one of"
@@ -31,28 +35,57 @@
 	@echo "  man        to make manual pages"
 	@echo "  texinfo    to make Texinfo files"
 	@echo "  info       to make Texinfo files and run them through makeinfo"
-	@echo "  gettext    to make PO message catalogs"
+	@echo "  gettext    to (re)generate the .pot file using sphinx gettext"
+	@echo "  locale     to compile .mo files from the .po files."
 	@echo "  changes    to make an overview of all changed/added/deprecated items"
 	@echo "  linkcheck  to check all external links for integrity"
 	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
 
 clean:
-	-rm -rf $(BUILDDIR)/*
+	-rm -rf $(BUILDDIR)/* $(PODIR)/.doctrees \
+	$(foreach lang,$(LANGS),$(PODIR)/$(lang)/)
 
-html:
+html: $(foreach lang,$(LANGS),html-$(lang))
+	# Always build an English version, even if there are no .po files.
 	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
-	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
+	mv $(BUILDDIR)/html/ubuntu-packaging-guide/*html $(BUILDDIR)/html/
+	sed -i 's/href="..\//href=".\//g' $(BUILDDIR)/html/*html
+	sed -i 's/..\/_images/.\/_images/g' $(BUILDDIR)/html/*html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html/en"
+html-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html/$*
+	mv $(BUILDDIR)/html/$*/ubuntu-packaging-guide/*html  $(BUILDDIR)/html/$*
+	sed -i 's/href="..\//href=".\//g' $(BUILDDIR)/html/$*/*html
+	sed -i 's/..\/_images/.\/_images/g' $(BUILDDIR)/html/$*/*html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html/$*."
+
+dirhtml: $(foreach lang,$(LANGS),dirhtml-$(lang))
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml/en
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml/en"
+dirhtml-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml/$*
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml/$*."
+
+singlehtml: $(foreach lang,$(LANGS),singlehtml-$(lang))
 	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
-	@echo
-	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+	sed -i 's/..\/..\//.\//g' _build/singlehtml/ubuntu-packaging-guide/index.html
+	sed -i 's/ubuntu-packaging-guide\/index/index/g' _build/singlehtml/ubuntu-packaging-guide/index.html
+	mv $(BUILDDIR)/singlehtml/ubuntu-packaging-guide/*html  $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml/en"
+singlehtml-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml/$*
+	# Work around upstream bug in singlehtml generation:
+	# https://bitbucket.org/birkenfeld/sphinx/issue/892/broken-singlehtml-when-files-are-in
+	sed -i 's/..\/..\//.\//g' _build/singlehtml/$*/ubuntu-packaging-guide/index.html
+	sed -i 's/ubuntu-packaging-guide\/index/index/g' _build/singlehtml/$*/ubuntu-packaging-guide/index.html
+	mv $(BUILDDIR)/singlehtml/$*/ubuntu-packaging-guide/*html  $(BUILDDIR)/singlehtml/$*
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml/$*."
 
 pickle:
 	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@@ -88,51 +121,87 @@
 	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ubuntu-packaging-guide"
 	@echo "# devhelp"
 
-epub:
+epub: $(foreach lang,$(LANGS),epub-$(lang))
 	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
 	@echo
-	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub"
+epub-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub/$*
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub/$*."
 
-latex:
+latex: $(foreach lang,$(LANGS),latex-$(lang))
 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
 	@echo
-	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Build finished; the LaTeX files are in is in $(BUILDDIR)/epub/en"
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+latex-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex/$*
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex/$*."
 	@echo "Run \`make' in that directory to run these through (pdf)latex" \
 	      "(use \`make latexpdf' here to do that automatically)."
 
-latexpdf:
+latexpdf: $(foreach lang,$(LANGS),latexpdf-$(lang))
 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
 	@echo "Running LaTeX files through pdflatex..."
 	make -C $(BUILDDIR)/latex all-pdf
-	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
-	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
-	@echo
-	@echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
-	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
-	@echo
-	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo
-	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
-	@echo "Run \`make' in that directory to run these through makeinfo" \
-	      "(use \`make info' here to do that automatically)."
-
-info:
-	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
-	@echo "Running Texinfo files through makeinfo..."
-	make -C $(BUILDDIR)/texinfo info
-	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+	mkdir -p $(BUILDDIR)/pdf; cp $(BUILDDIR)/latex/*pdf $(BUILDDIR)/pdf
+	@echo "Build finished; the PDF files are in $(BUILDDIR)/pdf"
+latexpdf-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex/$*
+	@echo "Running LaTeX files through pdflatex..."
+	make -C $(BUILDDIR)/latex/$* all-pdf
+	mkdir -p $(BUILDDIR)/pdf/$*; cp $(BUILDDIR)/latex/$*/*pdf $(BUILDDIR)/pdf/$*
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/pdf/$*."
+
+text: $(foreach lang,$(LANGS),text-$(lang))
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text/en
+	@echo
+	@echo "Build finished. The text pages are in $(BUILDDIR)/text/en"
+text-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text/$*
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text/$*."
+
+man: $(foreach lang,$(LANGS),man-$(lang))
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man/en
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man/en"
+man-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man/$*
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man/$*."
+
+texinfo: $(foreach lang,$(LANGS),texinfo-$(lang))
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo/en
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo/en."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+texinfo-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo/$*
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo/$*."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info: $(foreach lang,$(LANGS),info-$(lang))
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo/en
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo/en info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo/en."
+info-%: locale
+	$(SPHINXBUILD) -Dlanguage=$* -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo/$*
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo/$* info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo/$*."
 
 gettext:
-	$(SPHINXBUILD) -b gettext $(ALLSPHINXOPTS) $(BUILDDIR)/locale
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(PODIR)/
 	@echo
-	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+	@echo "Build finished. The message catalogs are in $(PODIR)/."
 
 changes:
 	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@@ -149,3 +218,10 @@
 	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
 	@echo "Testing of doctests in the sources finished, look at the " \
 	      "results in $(BUILDDIR)/doctest/output.txt."
+
+locale: $(foreach lang,$(LANGS),locale-$(lang))
+locale-%:
+	@echo "Compiling .mo files in $(PODIR)/$*/LC_MESSAGES"
+	mkdir -p $(PODIR)/$*/LC_MESSAGES
+	msgfmt po/$*.po -o po/$*/LC_MESSAGES/ubuntu-packaging-guide.mo
+

=== modified file 'conf.py'
--- conf.py	2012-02-27 18:07:17 +0000
+++ conf.py	2012-03-20 20:48:20 +0000
@@ -21,7 +21,7 @@
 # -- General configuration -----------------------------------------------------
 
 # If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
+needs_sphinx = '1.1'
 
 # Add any Sphinx extension module names here, as strings. They can be extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
@@ -37,11 +37,12 @@
 #source_encoding = 'utf-8-sig'
 
 # The master toctree document.
-master_doc = 'index'
+master_doc = 'ubuntu-packaging-guide/index'
 
 # General information about the project.
 project = u'ubuntu-packaging-guide'
-copyright = u'2010, Ubuntu Developers'
+authors = 'Ubuntu Developers'
+copyright = u'2010-2012, '+authors
 
 
 changelog = "debian/changelog"
@@ -74,7 +75,8 @@
 # directories to ignore when looking for source files.
 exclude_patterns = ['_build']
 
-locale_dirs = ["translated/"]
+locale_dirs = ["po/"]
+gettext_compact = True
 
 # The reST default role (used for this markup: `text`) to use for all documents.
 #default_role = None
@@ -188,7 +190,7 @@
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title, author, documentclass [howto/manual]).
 latex_documents = [
-  ('index', 'ubuntu-packaging-guide.tex', u'ubuntu-packaging-guide Documentation',
+  ('ubuntu-packaging-guide/index', 'ubuntu-packaging-guide.tex', u'ubuntu-packaging-guide Documentation',
    u'Ubuntu Developers', 'manual'),
 ]
 
@@ -221,7 +223,7 @@
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-    ('index', 'ubuntu-packaging-guide', u'ubuntu-packaging-guide Documentation',
+    ('ubuntu-packaging-guide/index', 'ubuntu-packaging-guide', u'ubuntu-packaging-guide Documentation',
      [u'Ubuntu Developers'], 1)
 ]
 
@@ -231,7 +233,7 @@
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-  ('index', 'ubuntu-packaging-guide', u'ubuntu-packaging-guide Documentation', u'Ubuntu Developers',
+  ('ubuntu-packaging-guide/index', 'ubuntu-packaging-guide', u'ubuntu-packaging-guide Documentation', u'Ubuntu Developers',
    'ubuntu-packaging-guide', 'One line description of project.', 'Miscellaneous'),
 ]
 
@@ -242,10 +244,10 @@
 # -- Options for Epub output ---------------------------------------------------
 
 # Bibliographic Dublin Core info.
-epub_title = u'ubuntu-packaging-guide'
-epub_author = u'Ubuntu Developers'
-epub_publisher = u'Ubuntu Developers'
-epub_copyright = u'2010, Ubuntu Developers'
+epub_title = project
+epub_author = authors
+epub_publisher = authors
+epub_copyright = copyright
 
 # The language of the text. It defaults to the language option
 # or en if the language is not set.

=== modified file 'debian/control'
--- debian/control	2011-04-19 09:08:45 +0000
+++ debian/control	2012-03-20 20:48:20 +0000
@@ -3,7 +3,8 @@
 Section: doc
 Maintainer: Ubuntu Developers <[e-mail]>
 Build-Depends: debhelper (>= 7.0.50~), python-sphinx (>= 1.0~), doc-base, 
- texlive-latex-base, texlive-latex-recommended, texlive-latex-extra, texlive-fonts-recommended
+ texlive-latex-base, texlive-latex-recommended, texlive-latex-extra,
+ texlive-fonts-recommended, fdupes
 Standards-Version: 3.9.1
 
 Package: ubuntu-packaging-guide

=== modified file 'debian/copyright'
--- debian/copyright	2012-02-24 10:46:44 +0000
+++ debian/copyright	2012-03-20 20:48:20 +0000
@@ -4,7 +4,7 @@
 Source: http://launchpad.net/ubuntu-packaging-guide
 
 Files: *
-Copyright: 2010-2011, Ubuntu Developers <[e-mail]>
+Copyright: 2010-2012, Ubuntu Developers <[e-mail]>
 License: CC-BY-SA-3.0
  Attribution-ShareAlike 3.0 Unported
  .

=== modified file 'debian/rules'
--- debian/rules	2012-01-18 20:21:22 +0000
+++ debian/rules	2012-03-20 20:48:20 +0000
@@ -9,4 +9,17 @@
 	make epub
 
 override_dh_compress:
-	dh_compress -X usr/share/doc/ubuntu-packaging-guide/html/_sources/
+	dh_compress -X usr/share/doc/ubuntu-packaging-guide/html/
+
+override_dh_link:
+	# symlink identical resources.
+	cd debian/ubuntu-packaging-guide && LC_ALL=C fdupes -r1nq \
+	usr/share/doc/ubuntu-packaging-guide/html | while read s; do \
+		set -- $$(echo $$s | tr ' ' '\n' | sort); \
+		f=$$1; shift; \
+		for d; do \
+			echo "symlinking identical file $$f to $$d"; \
+			rm $$f; ln -s /$$d $$f; \
+		done; \
+	done;
+	dh_link

=== modified file 'debian/ubuntu-packaging-guide.doc-base.single'
--- debian/ubuntu-packaging-guide.doc-base.single	2010-11-19 12:02:45 +0000
+++ debian/ubuntu-packaging-guide.doc-base.single	2012-03-20 20:48:20 +0000
@@ -7,7 +7,7 @@
 Section: Text
 
 Format: PDF
-Files: /usr/share/doc/ubuntu-packaging-guide/ubuntu-packaging-guide.pdf.gz
+Files: /usr/share/doc/ubuntu-packaging-guide/pdf/ubuntu-packaging-guide.pdf.gz
 
 Format: HTML
 Index: /usr/share/doc/ubuntu-packaging-guide/singlehtml/index.html

=== modified file 'debian/ubuntu-packaging-guide.docs'
--- debian/ubuntu-packaging-guide.docs	2010-11-19 12:02:45 +0000
+++ debian/ubuntu-packaging-guide.docs	2012-03-20 20:48:20 +0000
@@ -1,4 +1,4 @@
-_build/latex/*.pdf
+_build/pdf
 _build/html
 _build/epub
 _build/singlehtml

=== added directory 'po'
=== added file 'po/de.po'
--- po/de.po	1970-01-01 00:00:00 +0000
+++ po/de.po	2012-03-20 20:48:20 +0000
@@ -0,0 +1,3182 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) 2010-2012, Ubuntu Developers
+# This file is distributed under the same license as the ubuntu-packaging-guide package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: ubuntu-packaging-guide 0.1\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2012-02-29 17:52\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <[e-mail]>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../ubuntu-packaging-guide/chroots.rst:3
+# d6c7ecbd606c4b9282b23708db85f9b5
+msgid "Using Chroots"
+msgstr "Chroots benutzen"
+
+#: ../ubuntu-packaging-guide/chroots.rst:5
+# c2a9180a73924eb0b652907be2585c5d
+msgid "If you are running one version of Ubuntu but working on packages for another versions you can create the environment of the other version with a ``chroot``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:9
+# 6634399d63e843f4b72b0f770fafd076
+msgid "A ``chroot`` allows you to have a full filesystem from another distribution which you can work in quite normally.  It avoids the overhead of running a full virtual machine."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:14
+# feb922fa269d4d50913b3692dea2800f
+msgid "Creating a Chroot"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:16
+# 84f92237b55541a2b463749f2521ca05
+msgid "Use the command ``debootstrap`` to create a new chroot::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:20
+# 9208c7dbf8d84b5eb0fd24fab308ff5c
+msgid "This will create a directory ``oneiric`` and install a minimal oneiric system into it."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:23
+# 2f24711099184a0ba8f80c20edc1adc2
+msgid "If your version of ``debootstrap`` does not know about oneiric you can try upgrading to the version in ``backports``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:26
+# 0575a501ac4448359c69b30b55550435
+msgid "You can then work inside the chroot::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:30
+# 6b1f042f6de1476db33347866860441c
+msgid "Where you can install or remove any package you wish without affecting your main system."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:33
+# 9536d8f2c01e43648648496a446eeb6e
+msgid "You might want to copy your GPG/ssh keys and Bazaar configuration into the chroot so you can access and sign packages directly."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:36
+# e6d516f40fee4cc2972525ec9b13615e
+msgid "$ sudo mkdir oneiric/home/<username> $ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar oneiric/home/<username>"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:39
+# ed82e18debb24933ad3b49492b196442
+msgid "To stop apt and other programs complaining about missing locales you can install your relevant language pack::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:44
+# 7d9703bd6d9148daa5980a104d8d13ef
+msgid "If you want to run X programs you will need to bind the /tmp directory into the chroot, from outside the chroot run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:50
+# 3c056ca4d3b54c53bca74c2cc2025835
+msgid "Some programs may need you to bind /dev or /proc."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:52
+# 7164d56709d64a9e83edc09bf710fce7
+msgid "For more information on chroots see our `Debootstrap Chroot wiki page`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:55
+# 26aacfbeebe4473f9e1244c3c974b6ff
+msgid "Alternatives"
+msgstr "Alternativen"
+
+#: ../ubuntu-packaging-guide/chroots.rst:57
+# f085504840904fcb995131456d3036d7
+msgid "SBuild is a system similar to PBuilder for creating an environment to run test package builds in.  It closer matches that used by Launchpad for building packages but takes some more setup compared to PBuilder.  See `the Security Team Build Environment wiki page`_ for a full explanation."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:59
+# 9fa7e581df034a33a4503a7a41b37017
+msgid "Full virtual machines can be useful for packaging and testing programmes.  TestDrive is a program to automate syncing and running daily ISO images, see `the TestDrive wiki page`_ for more information."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:63
+# 112cec755e0d4ac5a0e1e20df59807f8
+msgid "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."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:67
+# 1367b95423434ae9b8d2687c8c100771
+msgid "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 version and package on those.  This is useful when you want to compile many packages at the same time or to overcome bandwidth restraints."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:3
+# 607298b09c134c8497b9dd820a18456f
+msgid "Communication in Ubuntu Development"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:5
+# 02e7427cdd1a4e48b9f0dfa256715944
+msgid "In a project where thousands of lines of code are changed, lots of decisions are made and hundreds of people interact every day, it is important to communicate effectively."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:10
+# 8dff4e5170734f698bbb51c6807b7dcf
+msgid "Mailing lists"
+msgstr "Mailinglisten"
+
+#: ../ubuntu-packaging-guide/communication.rst:12
+# 7bdd3f8f13b34307a06a05656c94760b
+msgid "Mailing lists are a very important tool if you want to communicate ideas to a broader team and make sure that you reach everybody, even across timezones."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:16
+# ec54a70a969342e58399443508c91e33
+msgid "In terms of development, these are the most important ones:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:18
+# c583284d21a5478e973448d96344c720
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (announce-only, the most important development announcements go here)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:20
+# 187731122f5045a09748d70e00456b4c
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (general Ubuntu development discussion)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:22
+# 38f45dd72cfd4f64bc0e64af440c45c2
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU Team discussion, get help with packaging)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:27
+# bcf8bf4cfd7d44e79964fc504e3dcbcf
+msgid "IRC Channels"
+msgstr "IRC-Kanäle"
+
+#: ../ubuntu-packaging-guide/communication.rst:29
+# 1640a1e73721469dbb00fb44535008f2
+msgid "For real-time discussions, please connect to irc.freenode.net and join one or any of these channels:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:32
+# 54b7cb96eed649698da71070bdcec51b
+msgid "#ubuntu-devel (for general development discussion)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:33
+# 9d87672ae32043ec8c0a9f2bca0b7dd4
+msgid "#ubuntu-motu (for MOTU team discussion and generally getting help)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:2
+# 89800d29a2d548768207920d6fb6d7b3
+msgid "Basic Overview of the ``debian/`` Directory"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:4
+# 7d1e060c05644770b508535c347508a1
+msgid "This article will briefly explain the different files important to the packaging of Ubuntu packages which are contained in the ``debian/`` directory. The most important of them are ``changelog``, ``control``, ``copyright``, and ``rules``. These are required for all packages. A number of additional files in the ``debian/`` may be used in order to customize and configure the behavior of the package. Some of these files are discussed in this article, but this is not meant to be a complete list."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:13
+# 3021836f0c23449690b60757ce61172a
+msgid "The changelog"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:15
+# 31bd62153b0d408bb34738128c941836
+msgid "This file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time. If you have a GPG key (see: :doc:`Getting set up<./getting-set-up/>`), make sure to use the same name and email address in ``changelog`` as you have in your key. The following is a template ``changelog``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:31
+# 615d3cedb82c4d399c625d3986b6c75e
+msgid "The format (especially of the date) is important. The date should be in :rfc:`5322` format, which can be obtained by using the command ``date -R``. For convenience, the command ``dch`` may be used to edit changelog. It will update the date automatically."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:36
+# 3d1b93961c0a46a4b77382e11822dd08
+msgid "Minor bullet points are indicated by a dash \"-\", while major points use an asterisk \"*\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:39
+# 3c8e29b2b199417083f23153de4c94c4
+msgid "If you are packaging from scratch, ``dch --create`` (``dch`` is in the ``devscripts`` package) will create a standard ``debian/changelog`` for you."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:43
+# 0f6505553bb0491d9f0247c37f87cf9a
+msgid "Here is a sample ``changelog`` file for hello::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:52
+# 3f1fd2f3b89a4e36aff77a170ba8c656
+msgid "Notice that the version has a ``-0ubuntu1`` appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:56
+# 8500e33e8dae496d9bab351d1f1f0a0d
+msgid "Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ``ubuntuX`` (where ``X`` is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello ``2.6-1`` package was changed by Ubuntu, the version string would be ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:64
+# 8a1028b5e61244339a21d8fdf991cd73
+msgid "For further information, see the `changelog section (Section 4.4) <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:70
+# 552ad1faf3814524bd838abbb1c6dfde
+msgid "The control file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:72
+# 0a7a9cd926a5482090b334ae4eb5fa76
+msgid "The ``control`` file contains the information that the package manager (such as ``apt-get``, ``synaptic``, and ``adept``) uses, build-time dependencies, maintainer information, and much more."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:76
+# 2c2caa9a9fef495dad29ffa07ab52d4a
+msgid "For the Ubuntu ``hello`` package, the ``control`` file looks something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:99
+# bd3ddeb9c3fd445ba6df546d419ec391
+msgid "The first paragraph describes the source package including the list of packages required to build the package from source in the ``Build-Depends`` field. It also contains some meta-information such as the maintainer's name, the version of Debian Policy that the package complies with, the location of the packaging version control repository, and the upstream home page."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:106
+# 93b0eec4843d4f819ba16118070fbbdf
+msgid "Note that in Ubuntu, we set the ``Maintainer`` field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team). Packages in Ubuntu should generally have the ``Maintainer`` field set to ``Ubuntu Developers <[e-mail]>``. If the Maintainer field is modified, the old value should be saved in the ``XSBC-Original-Maintainer`` field. This can be done automatically with the  ``update-maintainer`` script available in the ``ubuntu-dev-tools`` package. For further information, see the `Debian Maintainer Field spec <https://wiki.ubuntu.com/DebianMaintainerField>`_ on the Ubuntu wiki."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:118
+# 00ca42e43f314557af47bf373ae50fe6
+msgid "Each additional paragraph describes a binary package to be built."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:120
+# a48f51f0912a4312a904ab5f40ced13d
+msgid "For further information, see the `control file section (Chapter 5) <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:126
+# 870ce0ac216c4fd8a10aa642d5a8ee12
+msgid "The copyright file"
+msgstr "Die Copyright-Datei"
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:128
+# a8f880bcb0174968b217b52dfc303a34
+msgid "This file gives the copyright information for both the upstream source and the packaging. Ubuntu and `Debian Policy (Section 12.5) <http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>`_ require that each package installs a verbatim copy of its copyright and license information to ``/usr/share/doc/$(package_name)/copyright``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:134
+# 73c9109a50ce4e2c8d6ce22c64df57dd
+msgid "Generally, copyright information is found in the ``COPYING`` file in the program's source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. An example template would be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:176
+# 7a2e84d5a9304d2fb327fc2d39a75a45
+msgid "This example follows the `Machine-readable debian/copyright <http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>`_ format. You are encouraged to use this format as well."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:182
+# 7c0fe27bc8fa4cb192be460e57dde489
+msgid "The rules file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:184
+# 7c9e2edb563c4fe894feeae0b17007c7
+msgid "The last file we need to look at is ``rules``. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the ``.deb`` file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:192
+# 299ff74602f94f758774713d29895440
+msgid "Here is a simplified version of the rules file created by ``dh_make`` (which can be found in the ``dh-make`` package)::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:204
+# 94a7b044a9824b13b733ffe6b5ee57b5
+msgid "Let us go through this file in some detail. What this does is pass every build target that ``debian/rules`` is called with as an argument to ``/usr/bin/dh``, which itself will call all the necessary ``dh_*`` commands."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:208
+# de59039f8bd245d7971edf916d93a839
+msgid "``dh`` runs a sequence of debhelper commands. The supported sequences correspond to the targets of a ``debian/rules`` file: \"build\", \"clean\", \"install\", \"binary-arch\", \"binary-indep\", and \"binary\". In order to see what commands are run in each target, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:217
+# 7d39368e13994bedac97c6e43018bbb2
+msgid "Commands in the binary-indep sequence are passed the \"-i\" option to ensure they only work on binary independent packages, and commands in the binary-arch sequences are passed the \"-a\" option to ensure they only work on architecture dependent packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:222
+# 9aeaa267814c4f199174eb45833f25c2
+msgid "Each debhelper command will record when it's successfully run in ``debian/package.debhelper.log``. (Which dh_clean deletes.) So dh can tell which commands have already been run, for which packages, and skip running those commands again."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:227
+# efa044d38ff14eebb1b18fab6a0d594d
+msgid "Each time ``dh`` is run, it examines the log, and finds the last logged command that is in the specified sequence. It then continues with the next command in the sequence. The ``--until``, ``--before``, ``--after``, and ``--remaining`` options can override this behavior."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:232
+# d01ecd38632646f4b2bbaf1c8a08477d
+msgid "If ``debian/rules`` contains a target with a name like ``override_dh_command``, then when it gets to that command in the sequence, ``dh`` will run that target from the rules file, rather than running the actual command. The override target can then run the command with additional options, or run entirely different commands instead. (Note that to use this feature, you should Build-Depend on debhelper 7.0.50 or above.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:241
+# 3f4e235a68754876866310c506863f75
+msgid "Have a look at ``/usr/share/doc/debhelper/examples/`` and ``man dh`` for more examples. Also see `the rules section (Section 4.9) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:247
+# 909152843c7c41ffa14664f13cb0e23f
+msgid "Additional Files"
+msgstr "Zusätzliche Dateien"
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:250
+# f6ef0e8b2e5149f59850c2425711b97f
+msgid "The install file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:252
+# 526e3303d4d44e27a3ceefc4764a54c9
+msgid "The ``install`` file is used by ``dh_install`` to install files into the binary package. It has two standard use cases:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:255
+# 8f1de6bb1994494b807ec69b3af9e2ff
+msgid "To install files into your package that are not handled by the upstream build system."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:256
+# ecb71f5a256c4c0ab18dd78194054e68
+msgid "Splitting a single large source package into multiple binary packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:258
+# b540bec3330242b48b8b6c6f34cfacf6
+msgid "In the first case, the ``install`` file should have one line per file installed, specifying both the the file and the installation directory. For example, the following ``install`` file would install the script ``foo`` in the source package's root directory to ``usr/bin`` and a desktop file in the ``debian`` directory to ``usr/share/applications``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:269
+# cdd19fc100104c8ea9f0588252dfa8cb
+msgid "When a source package is producing multiple binary packages ``dh`` will install the files into ``debian/tmp`` rather than directly into ``debian/<package>``. Files installed into ``debian/tmp`` can then be moved into separate binary packages using multiple ``$package_name.install`` files. This is often done to split large amounts of architecture independent data out of architecture dependent packages and into ``Architecture: all`` packages. In this case, only the name of the files (or directories) to be installed are needed without the installation directory. For example, ``foo.install`` containing only the architecture dependent files might look like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:282
+# 490646dff688435088bd93ff30de6a8a
+msgid "While ``foo-common.install`` containing only the architecture independent file might look like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:290
+# ad5ae2bd9270403fb9916024351646c9
+msgid "This would create two binary packages, ``foo`` and ``foo-common``. Both would require their own paragraph in ``debian/control``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:293
+# ed10a77119a6408b8a5f7bfebc53500e
+msgid "See ``man dh_install`` and the `install file section (Section 5.11) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install>`_  of the Debian New Maintainers' Guide for additional details."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:298
+# 2bce7b3f508c457eb566c77de679acd7
+msgid "The watch file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:300
+# d22412241e7349bfa19c0ca46d59fa93
+msgid "The ``debian/watch`` file allows us to check automatically for new upstream versions using the tool ``uscan`` found in the ``devscripts`` package. The first line of the watch file must be the format version (3, at the time of this writing), while the following lines contain any URLs to parse. For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:309
+# 3fd98ffeb19c4a2290a8fec31eed399c
+msgid "Running ``uscan`` in the root source directory will now compare the upstream version number in ``debian/changelog`` with the latest available upstream version. If a new upstream version is found, it will be automatically downloaded. For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:322
+# a4a1f7731ea6433ca39eecbd57af3120
+msgid "For further information, see ``man uscan`` and the `watch file section (Section 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:326
+# 703b5d062b5c41e5a60cf8801b69b893
+msgid "For a list of packages where the ``watch`` file reports they are not in sync with upstream see `Ubuntu External Health Status <http://qa.ubuntuwire.org/uehs/no_updated.html>`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:331
+# faa634aa8992448d86ad70c8669ceee1
+msgid "The source/format file"
+msgstr "Die Datei source/format"
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:333
+# a348a6a009424e0fa49a866e129573a2
+msgid "This file indicates the format of the source package. It should contain a single line indicating the desired format:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:336
+# 3d75a73a1fcd4342ab1fe865edf49644
+msgid "``3.0 (native)`` for Debian native packages (no upstream version)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:338
+# fd11f4ebad4d45bcbac715f3d8d4cc92
+msgid "``3.0 (quilt)`` for packages with a separate upstream tarball"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:340
+# 1293ceef3ce04d30b640542aec2b476c
+msgid "``1.0`` for packages wishing to explicitly declare the default format"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:342
+# 4e5d823b97ab4704aba10fb129ed0106
+msgid "Currently, the package source format will default to 1.0 if this file does not exist. You can make this explicit in the source/format file. If you choose not to use this file to define the source format, Lintian will warn about the missing file. This warning is informational only and may be safely ignored."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:347
+# d7047d3e7c22489baedfec02eea21f25
+msgid "You are encouraged to use the newer 3.0 source format. It provides a number of new features:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:350
+# bc4e7971f98848ae9f1fb3fd8ee97ace
+msgid "Support for additional compression formats: bzip2, lzma and xz"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:352
+# ddca8f575fac40e09adebd6d128ff676
+msgid "Support for multiple upstream tarballs"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:354
+# aded08ffbdb7449d88dd6010fd97766f
+msgid "Not necessary to repack the upstream tarball to strip the debian directory"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:356
+# b0f4d5d0c68e47de9ed8836f20a0e8be
+msgid "Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches compatible with quilt under ``debian/patches/``"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:358
+# 39b0c8ccca7e48b7af1af09d580e9f58
+msgid "http://wiki.debian.org/Projects/DebSrc3.0 summarizes additional information concerning the switch to the 3.0 source package formats."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:361
+# 9d2f31ea080c47109ce2cdae3e87f14b
+msgid "See ``man dpkg-source`` and the `source/format section (Section 5.21) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcef>`_  of the Debian New Maintainers' Guide for additional details."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:366
+# 62fbf7d7bdcb49e782e64f2623b6f273
+msgid "Additional Resources"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:368
+# 039aa564015a48bda02c00b97d1ae2f3
+msgid "In addition to the links to the Debian Policy Manual in each section above, the Debian New Maintainers' Guide has more detailed descriptions of each file. `Chapter 4, \"Required files under the debian directory\" <http://www.debian.org/doc/maint-guide/dreq.en.html>`_ further discusses the control, changelog, copyright and rules files. `Chapter 5, \"Other files under the debian directory\" <http://www.debian.org/doc/maint-guide/dother.en.html>`_ discusses additional files that may be used."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:3
+# 4be28eeaaecb4fffa9bcfb62c8828b58
+msgid "Fixing a bug in Ubuntu"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:6
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:9
+# 5973d64df73b4f8593c75fcac478a00e
+# e0956744ffbc47c08a5bb87b139bb113
+msgid "Introduction"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:8
+# d4425948fa1e4b4fa3552113dc4dd00d
+msgid "If you followed the instructions to :doc:`get set up with Ubuntu Development<./getting-set-up>`, you should be all set and ready to go."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:11
+# 02b036432f59412c82aed419f79fdb8c
+msgid "..image:: |IMG|fixing-a-bug.png"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:13
+# 565e30b78a5c41b8990814dc8aaf9193
+msgid "As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:20
+# 65a1fad6a3d04bbf8fc8932a8dbf6061
+msgid "Finding the problem"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:22
+# e8e70d62917543ed8b9b8f081ba09518
+msgid "There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:26
+# 1c114b6ed4044179acbfa298d17e8687
+msgid "`Harvest <http://harvest.ubuntu.com/>`_ is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them 'bitesize'), and so on. Check it out and find your first bug to work on."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:35
+# b454c63458594749aa09f9e587ed24a7
+msgid "Figuring out what to fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:37
+# e80c8c6721fe41ddb9d3976bea810f18
+msgid "If you don't know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you'll need to work on."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:41
+# 4726f96b219c4bfeb111d18b723e771e
+msgid "Let's say you've found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running ``/usr/bin/tomboy`` on the command line.  To find the binary package containing this application, use this command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:48
+# dbf4f211a56f4f79b15bf42c6a835050
+msgid "This would print out::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:52
+# 682b18dbdfe142d2affc3e04e843783f
+msgid "Note that the part preceding the colon is the binary package name.  It's often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages.  To find the source package for a particular binary package, type::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:64
+# b7321dfe18ed434689e1617b5ad1b575
+msgid "Getting the code"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:66
+# a88040229e1343e3a881389f2388861f
+msgid "Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it.  In Ubuntu Distributed Development this is done by :ref:`*branching* the source package <branching>` branch corresponding to the source package.  Launchpad maintains source package branches for all the packages in Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:72
+# 92bb0cef4a5a4924afaff6a5bd97394f
+msgid "Once you've got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch.  When you are happy with your fix, you can :ref:`submit a *merge proposal* <merge-proposal>`, which asks other Ubuntu developers to review and approve your change.  If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit of your excellent fix - and you get a little bit of credit.  You're now on your way to becoming an Ubuntu developer!"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:81
+# 18ebcba0d9804cdcbd3d7b679124afba
+msgid "We'll describe specifics on how to branch the code, push your fix, and request a review in the following sections."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:86
+# e8950446f9d643f9a88454cb13406165
+msgid "Work on a fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:88
+# 0b597e2df21d4ffb9082682062b35f5b
+msgid "There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:93
+# 1cad1f33d073486abd5bbd7950da19e1
+msgid "Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:96
+# 9cd02b0b46194cb0a6e1c024c73d67bb
+msgid "Upstream (and Debian) bug tracker (open and closed bugs),"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:97
+# fe3658bb50d6453d839bae201ab3e0d3
+msgid "Upstream revision history (or newer release) might have fixed the problem,"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:98
+# dc982aac83c44804b15e226836d039fd
+msgid "bugs or package uploads of Debian or other distributions."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:103
+# 3d5234f7f891414eac096bc475484247
+msgid "You now want to create a patch which includes the fix.  The command ``edit-patch`` is a simple way to add a patch to a package. Run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:108
+# e09e4812312c4fdc854bd3814b092ebb
+msgid "This will copy the packaging to a temporary directory.  You can now edit files with a text editor or apply patches from upstream, for example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:113
+# 8e00895b4bf64119869e26ce978cb55b
+msgid "After editing the file type ``exit`` or press ``control-d`` to quit the temporary shell.  The new patch will have been added into ``debian/patches``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:118
+# a5e56006a7db42a2b5b976f351e1a93a
+msgid "Testing the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:120
+# 29f45bb94cae448f9ff6bd53897237ab
+msgid "To build a test package with your changes, run these commands::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:125
+# 6fd80448fb9b40668a73b68d9aa82ee9
+msgid "This will create a source package from the branch contents (``-us -uc`` will just omit the step to sign the source package) and ``pbuilder-dist`` will build the package from source for whatever ``release`` you choose."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:129
+# 7064dcf9f1ae4f49bacc8b5ebb79a4fb
+msgid "Once the build succeeds, install the package from ``~/pbuilder/<release>_result/`` (using ``sudo dpkg -i <package>_<version>.deb``).  Then test to see if the bug is fixed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:136
+# a498c34018d44bc083c421d3836bc292
+msgid "Documenting the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:138
+# 284aad9da256489bb9541ef9c9ed8050
+msgid "It is very important to document your change sufficiently so developers who look at the code in the future won't have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes ``debian/changelog``, where changes of each uploaded package are tracked."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:143
+# c560a925fc79452f85c60a462422febd
+msgid "The easiest way to update this is to run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:147
+# fc6305e6f22b4bbe8f7ae46d9d2d36fe
+msgid "This will add a boilerplate changelog entry for you and launch an editor where you can fill in the blanks. An example of this could be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:156
+# b4fcf5a54df94852b901b81d99177166
+msgid "``dch`` should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is 'low'). The last line always contains the name, email address and timestamp (in :rfc:`5322` format) of the change."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:162
+# 245b3f4735b2450db24ddca21be8e504
+msgid "With that out of the way, let's focus on the actual changelog entry itself: it is very important to document:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:165
+# 43f30ecd000741b2849656bfa9c6ae55
+msgid "where the change was done"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:166
+# 6aa10c8f84ff4278888e5edc11cfdf66
+msgid "what was changed"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:167
+# a48a34986f8248b891f819d4abcff85c
+msgid "where the discussion of the change happened"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:169
+# b5105651513148e58182645ef1350d2b
+msgid "In our (very sparse) example the last point is covered by ``(LP: #123456)`` which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the ``LP: #<number>`` notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:178
+# 7e3ca41954e44f68bcbe1755d6a53f74
+msgid "Committing the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:180
+# 8931133984c348d5991fb0d11db638e0
+msgid "With the changelog entry written and saved, you can just run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:184
+# 694988e85f33437b9af1ab2c8a9192af
+msgid "and the change will be committed (locally) with your changelog entry as a commit message."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:187
+# c7c33ddc56cd406cb79afea806a24ab7
+msgid "To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:192
+# d43eb74f6725404a8e0c12ee36207d3d
+msgid "This could for example be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:196
+# 9c95cd25baca4246bf40816093dc7f7a
+msgid "So if you just run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:201
+# 5aa8ae3e79484b43bf7f43d93010513b
+msgid "you should be all set. The push command should push it to Launchpad and the second command will open the Launchpad page of the remote branch in your browser. There find the \"(+) Propose for merging\" link, click it to get the change reviewed by somebody and included in Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:3
+# 83f85e65560046f4b62f45e17b49a17a
+msgid "Getting Set Up"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:5
+# a66b7a19ac434a5a909505514b2926ca
+msgid "There are a number of things you need to do to get started developing for Ubuntu. This article is designed to get your computer set up so that you can start working with packages, and upload your packages to Ubuntu's hosting platform, Launchpad. Here's what we'll cover:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:10
+# 086a9c5ecf2d449b82843d303d58a164
+msgid "Installing packaging-related software. This includes:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:12
+# 400b8ae2a4554bb484ea4554b8fdd56d
+msgid "Ubuntu-specific packaging utilities"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:13
+# e062bc0cc3ed4294b33616a98d4a5a4d
+msgid "Encryption software so your work can be verified as being done by you"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:14
+# 925d91caef104cb7afa6001f05680be9
+msgid "Additional encryption software so you can securely transfer files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:16
+# b0e396c2d5f4463c96d854f06c659d6a
+msgid "Creating and configuring your account on Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:17
+# 4d333df7195b41f6b125d660b2a1c300
+msgid "Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:22
+# 9c69c6eea045429a8a34b6fe96139751
+msgid "It is advisable to do packaging work using the current development version of Ubuntu. Doing so will allow you to test changes in the same environment where those changes will actually be applied and used."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:26
+# 7c484a283dd34e39a18323d9beac87f9
+msgid "Don't worry though, the `Ubuntu development release wiki page <https://wiki.ubuntu.com/UsingDevelopmentReleases>`_ shows a variety of ways to safely use the development release."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:32
+# b98ebc64ff574a5dbf0bdbd1df7a6c8f
+msgid "Install basic packaging software"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:34
+# 808a29c5f38f448eb25ca66e04792f0f
+msgid "There are a number of tools that will make your life as an Ubuntu developer much easier.  You will encounter these tools later in this guide.  To install most of the tools you will need run this command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:41
+# fac16697cacf4355a80e8f5b88f324a0
+msgid "Note: Since Ubuntu 11.10 \"Oneiric Ocelot\" (or if you have Backports enabled on a currently supported release), the following command will install the above and other tools which are quite common in Ubuntu development::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:49
+# 49e40cea430146ec8c2692a2a6bcd425
+msgid "This command will install the following software:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:51
+# 4e959df03bee4ba6a973d4f2cbffec9d
+msgid "``gnupg`` -- `GNU Privacy Guard`_ contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:54
+# 1c457996b9ff49cfb8720509a4314a6d
+msgid "``pbuilder`` -- a tool to do a reproducible builds of a package in a clean and isolated environment."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:56
+# e9c0f3fd07be45c2928f88eb383771ed
+msgid "``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a collection of tools that make many packaging tasks easier."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:58
+# 29db292e4464422eb0e4e6222af33ef5
+msgid "``bzr-builddeb`` (and ``bzr``, a dependency) -- distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:62
+# 9f5925a4d2014953af7c6070b31a157c
+msgid "``apt-file`` provides an easy way to find the binary package that contains a given file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:64
+# 2110c86d771140b7bc69c2958b28464d
+msgid "``apt-cache`` (part of the ``apt`` package) provides even more information about packages on Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:69
+# 0a14b46fec014f97bd7557e4d9258941
+msgid "Create your GPG key"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:71
+# 16d8e0261d5a48dfb0ff6aeede808b34
+msgid "GPG stands for `GNU Privacy Guard`_ and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:78
+# c25b4a7c3abd47c4adab9c0d4a8f88e4
+msgid "To generate a new GPG key, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:82
+# 854929b1b9b74e56a91d8cdac1b6ccbf
+msgid "GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say \"0\", which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. Then you will have to set a passphrase, choose a safe one (a passphrase is just a password which is allowed to include spaces)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:92
+# c9411759e55c44f7b4ff04ab876850e9
+msgid "Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine.  Move the cursor around, type some paragraphs of random text, load some web page."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:97
+# 671e66dd26de4cc19167919c4cacf056
+msgid "Once this is done, you will get a message similar to this one::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:104
+# fbcfbe47756f426092c3860dad3c1fec
+msgid "In this case ``43CDE61D`` is the *key ID*."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:106
+# 5bcf72402a81478a8210db244d7a62f9
+msgid "Next, you need to upload the public part of your key to a keyserver so the world can identify messages and files as yours. To do so, enter::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:111
+# 457a5844d06c44969821537e48cdf762
+msgid "This will send your key to one keyserver, but a network of keyservers will automatically sync the key between themselves. Once this syncing is complete, your signed public key will be ready to verify your contributions around the world."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:118
+# bbd6cfc0f36241b9afc8304a4955b10f
+msgid "Create your SSH key"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:120
+# cbe44e54369c43ccbaf972bb10995704
+msgid "SSH_ stands for *Secure Shell*, and it is a protocol that allows you to exchange data in a secure way over a network. It is common to use SSH to access and open a shell on another computer, and to use it to securely transfer files. For our purposes, we will mainly be using SSH to securely upload source packages to Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:126
+# 15220156465043d89c0f0a526b3ae31d
+msgid "To generate an SSH key, enter::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:130
+# 4369607909e54d2eb28b701b18832582
+msgid "The default file name usually makes sense, so you can just leave it as it is. For security purposes, it is highly recommended that you use a passphrase."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:135
+# 4709c05c499e4a29bd71f5f1aef90b23
+msgid "Set up pbuilder"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:137
+# 74362386ed8340f2b5c45b2bdb9a08da
+msgid "``pbuilder`` allows you to build packages locally on your machine. It serves a couple of purposes:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:140
+# 93aa3aaf40b44beb8662c330374e4e50
+msgid "The build will be done in a minimal and clean environment. This helps you make sure your builds succeed in a reproducible way, but without modifying your local system"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:143
+# 5169282689aa4be29c874e27633030f0
+msgid "There is no need to install all necessary *build dependencies* locally"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:144
+# c97e8554b32d4e71965f1ff6479f13b6
+msgid "You can set up multiple instances for various Ubuntu and Debian releases"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:146
+# 6a4d016f67b64cf3bbe9148306cbb3b8
+msgid "Setting ``pbuilder`` up is very easy, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:150
+# fa64536c0c324d27983772c20599b26c
+msgid "where <release> is for example `natty`, `maverick`, `lucid` or in the case of Debian maybe `sid`. This will take a while as it will download all the necessary packages for a \"minimal installation\". These will be cached though."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:156
+# 5dc23eff94724361a73a59dea44289e7
+msgid "Get set up to work with Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:158
+# 95fadc8adf9f4a0e91bac3115a3d0cf1
+msgid "With a basic local configuration in place, your next step will be to configure your system to work with Launchpad. This section will focus on the following topics:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:162
+# b79f07693785483782ed6821e0a0b9ef
+msgid "What Launchpad is and creating a Launchpad account"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:163
+# e32ac038b50b4d829f13044673ba85bc
+msgid "Uploading your GPG and SSH keys to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:164
+# 50d201d98b2747bf9b900ebd2033d4b6
+msgid "Configuring Bazaar to work with Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:165
+# 2fcbff75feec47c890b29ae9a0accc58
+msgid "Configuring Bash to work with Bazaar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:169
+# 7d3092a6e1a142afa5c22a094e2be344
+msgid "About Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:171
+# c032fdb17ad44f8a9972c7b1160387dd
+msgid "Launchpad is the central piece of infrastructure we use in Ubuntu. It not only stores our packages and our code, but also things like translations, bug reports, and information about the people who work on Ubuntu and their team memberships.  You will also use Launchpad to publish your proposed fixes, and get other Ubuntu developers to review and sponsor them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:177
+# ad9d175d99654dad8e2c830c4beecab0
+msgid "You will need to register with Launchpad and provide a minimal amount of information. This will allow you to download and upload code, submit bug reports, and more."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:181
+# 0c25cf1d67e14ebc9621decebd78ef5c
+msgid "Besides hosting Ubuntu, Launchpad can host any Free Software project. For more information see the `Launchpad Help wiki <https://help.launchpad.net/>`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:186
+# 1060bd4edaa345a9a90d8c2e34628202
+msgid "Get a Launchpad account"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:188
+# 308e70601909430d842502f21e1589ad
+msgid "If you don't already have a Launchpad account, you can easily `create one`_. If you have a Launchpad account but cannot remember your Launchpad id, you can find this out by going to https://launchpad.net/~ and looking for the part after the `~` in the URL."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:193
+# a0e1270b66884075a0074a83105aded1
+msgid "Launchpad's registration process will ask you to choose a display name. It is encouraged for you to use your real name here so that your Ubuntu developer colleagues will be able to get to know you better."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:197
+# 7f4a08d3ce224e59b0d23ba2f4bc4b15
+msgid "When you register a new account, Launchpad will send you an email with a link you need to open in your browser in order to verify your email address. If you don't receive it, check in your spam folder."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:201
+# ff7522539ab64385b5e3460fec3e6c7f
+msgid "`The new account help page <https://help.launchpad.net/YourAccount/NewAccount>`_ on Launchpad has more information about the process and additional settings you can change."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:207
+# 8a4be4c66e1e4e4bbd19c1d319bb28bc
+msgid "Upload your GPG key to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:209
+# 506b5b99e7ac4c87ae989c190b86e41a
+msgid "To find about your GPG fingerprint, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:213
+# 472d7ced0c4c4d6da22703585fa46fe7
+msgid "and it will print out something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:221
+# 0c821916735d4f45a78d52e91ef3239e
+msgid "Head to https://launchpad.net/~/+editpgpkeys and copy the \"Key fingerprint\" into the text box. In the case above this would be ``5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D``. Now click on \"Import Key\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:226
+# ec669b136a8c42269d9abfeb85d34c09
+msgid "Launchpad will use the fingerprint to check the Ubuntu key server for your key and, if successful, send you an encrypted email asking you to confirm the key import. Check your email account and read the email that Launchpad sent you. `If your email client supports OpenPGP encryption, it will prompt you for the password you chose for the key when GPG generated it. Enter the password, then click the link to confirm that the key is yours.`"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:233
+# f08b21d4e43b485194ec184975a04f7f
+msgid "Launchpad encrypts the email, using your public key, so that it can be sure that the key is yours. If your email software does not support OpenPGP encryption, copy the encrypted email's contents, type ``gpg`` in your terminal, then paste the email contents into your terminal window."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:238
+# b7455eb7f4da4959b24ef5339b994d19
+msgid "Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:241
+# 8b0f15062c314bd5bc0578ab0db7233b
+msgid "Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:245
+# c7408c90022943d2b2adb9e67b8c079d
+msgid "Upload your SSH key to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:247
+# d55a8885d648402ebc1c8bfa9de5b62a
+msgid "Open https://launchpad.net/~/+editsshkeys in a web browser, also open ``~/.ssh/id_rsa.pub`` in a text editor. This is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says \"Add an SSH key\". Now click \"Import Public Key\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:253
+# d94df3105f334f17a6b8b4493abb7237
+msgid "For more information on this process, visit the `<creating an SSH keypair <https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair>`_ page on Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:259
+# 8452a24ce68f4df6ac5e44518ef879ad
+msgid "Configure Bazaar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:261
+# 2200087023b540598f73cba55e6d1e43
+msgid "Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently.  It is used for the new Ubuntu Distributed Development method of working with Ubuntu packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:266
+# 6809b71125db4a1c9a7039c20642d0c5
+msgid "To tell Bazaar who you are, simply run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:271
+# a7bbc2cbc2104be08887d3f357de5253
+msgid "`whoami` will tell Bazaar which name and email address it should use for your commit messages. With `launchpad-login` you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:275
+# b91245d32a2440a583e602e2b0c85ac3
+msgid "Note: If you can not remember the ID, go to https://launchpad.net/~ and see where it redirects you. The part after the \"~\" in the URL is your Launchpad ID.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:281
+# e267401effd84ebe9fad680ad51c3cd9
+msgid "Configure your shell"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:282
+# c497e7fe9aed473fac7283134a606445
+msgid "Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your `~/.bashrc` in a text editor and add something like this to the bottom of it::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:289
+# f1400dd33613411caa2495b24cb8901b
+msgid "Now save the file and either restart your terminal or run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:293
+# 71fcef52c0ce4c6a9f9e098c4f35cd1a
+msgid "(If you do not use the default shell, which is `bash`, please edit the configuration file for that shell accordingly.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:7
+# 2b2c79c0f4744aa6ac31ab4d14510523
+msgid "Ubuntu Packaging Guide"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:9
+# 2804b34604314864a75fcd88568b92f0
+msgid "Ubuntu is not only a free and open source operating system, its platform is also open and developed in a transparent fashion. The source code for every single component can be obtained easily and every single change to the Ubuntu platform can be reviewed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:14
+# e4717243c36b4fbaa8a4ab4731b7c6a2
+msgid "This means you can actively get involved in improving it and the community of Ubuntu platform developers is always interested in helping peers getting started."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:18
+# a8931d21f1314e2abf31996f75be3676
+msgid "The guide is split up into two sections:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:20
+# 4432017dc60141218901d1062a4db48d
+msgid "A list of articles based on tasks, things you want to get done."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:21
+# 0d65327272d34bd094988cd9f7ec6044
+msgid "A set of knowledge-base articles that dig deeper into specific bits of our tools and workflows."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:24
+# e9691f9962684fa2983959309c708dc6
+msgid "This guide focuses on the Ubuntu Distributed Development packaging method. This is a new way of packaging which uses Distributed Revision Control branches.  It currently has some limitations which mean many teams in Ubuntu use :doc:`traditional packaging<./traditional-packaging>` methods.  See the :doc:`UDD Introduction<./udd-intro>` page for an introduction to the differences."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:31
+# 35611cc67071493d95b0fd914f093f18
+msgid "Articles"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:46
+# 341532acc9554b0d9d4a83f5a043fdf9
+msgid "Knowledge Base"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:3
+# 795cb22fada7442f821a6d3640677ae7
+msgid "Introduction to Ubuntu Development"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:5
+# d1e2a2fc83084defb2029936d7af82db
+msgid "Ubuntu is made up of thousands of different components, written in many different programming languages. Every component -  be it a software library, a tool or a graphical application - is available as a source package. Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:14
+# d092727879c148148df7ae3a396ba4c1
+msgid "Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad's build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in ``/etc/apt/sources.list`` point to an archive or mirror. Every day CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:24
+# 6e37b4d95d8541b7aa3011844140dfd8
+msgid "Ubuntu's development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes. Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. The rest of the cycle is supposed to be focused on fixing bugs. After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:39
+# 3095f0dc21b845bd9adafbc230310de6
+msgid "Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. This is all done in an open and transparent fashion, so even if you can not attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:51
+# c2c9a07df8734bcd84811b0d08005493
+msgid "Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:58
+# 89290a1fefbc4e5a87353e069aeb79ac
+msgid "Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:65
+# 224c0402acf54540b6e21eb5498d8bf9
+msgid "Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. These projects are called \"Upstreams\", because their source code flows into Ubuntu, where we \"just\" integrate it. The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:74
+# 7b06da07d99842fd9738c38140dd2a16
+msgid "The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:83
+# c04e0435ba0d4bb38160660e3cda4ca0
+msgid "Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:88
+# 72ea8fca34b04f5eb28aae4b06eaa638
+msgid "Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix. That is why we make use of \"Distributed Development\", where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:98
+# 38a1680f15f04e2785f959f32e8b7311
+msgid "In the example mentioned above it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:103
+# b1e0446cdaa9426cb9aa082ca826788c
+msgid "To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:112
+# fa9b32a2c49847f7b576db0fbf94036c
+msgid "When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:116
+# 471fe59800924fc88bb010d19ea956f0
+msgid "Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:119
+# f36cfc93f9314451b2f5756d1652f425
+msgid "The most important requirements for success in Ubuntu development are: having a knack for \"making things work again,\" not being afraid to read documentation and ask questions, being a team player and enjoying some detective work."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:123
+# 7d209126020141168c019c68053e2abd
+msgid "Good places to ask your questions are ``[e-mail]`` and ``#ubuntu-motu`` on ``irc.freenode.net``. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:3
+# 993a9c1aa71f4aadadde6a86b5ef2ed3
+msgid "KDE Packaging"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:5
+# f8f58e55f37f4abcaa7264f5fdc83903
+msgid "Packaging of KDE programmes 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 about Kubuntu development is on the `Kubuntu wiki page`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:10
+# dc2e9c6e5402441f85737795e60858fc
+msgid "Our packaging follows the practices of the ``Debian Qt/KDE Team`` and Debian KDE Extras Team.  Most of our packages are derived from the packaging of these Debian teams."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:15
+# a38db20adbbe4a7da13b3d8559127a47
+msgid "Patching Policy"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:17
+# ac62cb4c0e664dd4b78c074e72f87171
+msgid "Kubuntu does not add patches to KDE programmes unless they come from the upstream authors or submitted upstream with the expectation they will be merged soon or we have consulted the issue with the upstream authors."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:22
+# cb2134c6ba4346458b922470c90a372f
+msgid "Kubuntu does not change the branding of packages except where upstream expects this (such as the top left logo of the Kickoff menu) or to simplify (such as removing splash screens)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:27
+# d51900d276b44514b5d0c25d00914f01
+msgid "debian/rules"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:29
+# 1311b27e75554f01874d2417d4a5b9bf
+msgid "Debian packages include some additions to the basic Debhelper usage. These are kept in the ``pkg-kde-tools`` package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:32
+# 4bb8cca6f7f940dc84f4ea1798287277
+msgid "Packages which use Debhelper 7 should add the ``--with=kde`` option. This will ensure the correct build flags are used and add options such as handling kdeinit stubs and translations::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:39
+# 4a5e3298265c4fd4a8df97acde2c69f0
+msgid "Some newer KDE packages use the ``dhmk`` system, an alternative to ``dh`` made by the Debian Qt/KDE team.  You can read about it in /usr/share/pkg-kde-tools/qt-kde-team/2/README.  Packages using this will ``include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk`` instead of running ``dh``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:47
+# 15bc35a1eefa4bee8ed9330f9a044380
+msgid "Translations"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:49
+# ffae416394ec437c93e62703e46d4c93
+msgid "Packages in main have their translations imported into Launchpad and exported from Launchpad into Ubuntu's language-packs."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:52
+# e2265cab7d764b4b83529d3b24129102
+msgid "So any KDE package in main must generate translation templates, include or make available upstream translations and handle ``.desktop`` file translations."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:56
+# 98fc332176d84794aafa13b935d98523
+msgid "To generate translation templates the package must include a ``Messages.sh`` file; complain to the upstream if it does not.  You can check it works by running ``extract-messages.sh`` which should produce one or more ``.pot`` files in ``po/``.  This will be done automatically during build if you use the ``--with=kde`` option to ``dh``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:63
+# 931ea74ab2164fe8a5a982500456cbb2
+msgid "Upstream will usually have also put the translation ``.po`` files into the ``po/`` directory.  If they do not, check if they are in separate upstream language packs such as the KDE SC language packs.  If they are in separate language packs Launchpad will need to associate these together manually, contact `dpm`_ to do this."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:69
+# 52573e8867ac4ed2840f572b9facbcb9
+msgid "If a package is moved from universe to main it will need to be reuploaded before the translations get imported into Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:72
+# 198ae177145b49b285220a56326dd9ce
+msgid "``.desktop`` files also need translations.  We patch KDELibs to read translations out of ``.po`` files which are pointed to by a line ``X-Ubuntu-Gettext-Domain=`` added to ``.desktop`` files at package build time.  A .pot file for each package is be generated at build time and .po files need to be downloaded from upstream and included in the package or in our language packs.  The list of .po files to be downloaded from KDE's repositories is in ``/usr/lib/kubuntu-desktop-i18n/desktop-template-list``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:82
+# b49c7bc8627b48a7b4931ebd99bb725d
+msgid "Library Symbols"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:84
+# a20fa5bcd911465789f7e4c2dfd61207
+msgid "Library symbols are tracked in ``.symbols`` files to ensure none go missing for new releases.  KDE uses C++ libraries which act a little differently compared to C libraries.  Debian's Qt/KDE Team have scripts to handle this. See `Working with symbols files`_ for how to create and keep these files up to date."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:3
+# 1161adad2b574c3dae7242a0e177d3cb
+msgid "Shared Libraries"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:5
+# e5417138b06748e7b459aee1467052f7
+msgid "Shared libraries are compiled code which is intended to be shared among several different programmes.  They are distributed as ``.so`` files in ``/usr/lib/``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:9
+# 3ea2eb4efb504f41812aad3d3a3630c0
+msgid "A library exports symbols which are the compiled versions of functions, classes and variables.  A library has a name called an SONAME which includes a version number.  This SONAME version does not necessarily match the public release version number.  A programme gets compiled against a given SONAME version of the library.  If any of the symbols is removed or changes then the version number needs to be changed which forces any packages using that library to be recompiled against the new version.  Version numbers are usually set by upstream and we follow them in our binary package names called an ABI number, but sometimes upstreams do not use sensible version numbers and packagers have to keep separate version numbers."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:21
+# 07915fe981c94c4db90837dba30d3cc0
+msgid "Libraries are usually distributed by upstream as standalone releases. Sometimes they are distributed as part of a programme.  In this case they can be included in the binary package along with the programme (this is called bundling) if you do not expect any other programmes to use the library, more often they should be split out into separate binary packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:27
+# 4c5c66ef19a44914bee41dc0539099fa
+msgid "The libraries themselves are put into a binary package named ``libfoo1`` where ``foo`` is the name of the library and ``1`` is the version from the SONAME. Development files from the package, such as header files, needed to compile programmes against the library are put into a package called ``libfoo-dev``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:34
+# 06a1e94fcbba4e9eadba9eb114a9c642
+msgid "An Example"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:36
+# a1ec3bc9d692403ab82b43da77562aae
+msgid "We will use libnova as an example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:41
+# cd3c9fa86411468aaf013cfabc0fdb33
+msgid "To find the SONAME of the library run"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:43
+# 0af012c44f39480b8014cfa20b67b08f
+msgid "$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:45
+# 379239ed35f840b1b788703c94ef817f
+msgid "The SONAME is ``libnova-0.12.so.2``, which matches the file name (usually the case but not always). Here upstream has put the upstream version number as part of the SONAME and given it an ABI version of ``2``.  Library package names should follow the SONAME of the library they contain. The library binary package is called ``libnova-0.12-2`` where ``libnova-0.12`` is the name of the library and ``2`` is our ABI number."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:52
+# 122c0516404646858c5e64bbaf93311e
+msgid "If upstream makes incompatible changes to their library they will have to reversion their SONAME and we will have to rename our library.  Any other packages using our library package will need to recompiled against the new version, this is called a transition and can take some effort. Hopefully our ABI number will continue to match upstream's SONAME but sometimes they introduce incompatibilities without changing their version number and we will need to change ours."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:60
+# 5bb0db11faef4045a6ffa4ff6a360ada
+msgid "Looking in debian/libnova-0.12-2.install we see it includes two files::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:65
+# e694ef09fee449688473a2417d7e4de3
+msgid "The last one is the actual library, complete with minor and point version number.  The first one is a symlink which points to the actual library.  The symlink is what programmes using the library will look for, the running programmes do not care about the minor version number."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:70
+# 4806076bc944430598072095813eaf39
+msgid "``libnova-dev.install`` includes all the files needed to compile a programme with this library.  Header files, a config binary, the ``.la`` libtool file and ``libnova.so`` which is another symlink pointing at the library, programmes compiling against the library do not care about the major version number (although the binary they compile into will)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:76
+# 4d4773c47d50413e9e4c9f1163445e3c
+msgid "``.la`` libtool files are needed on some non-Linux systems with poor library support but usually cause more problems than they solve on Debian systems.  It is a current `Debian goal to remove .la files`_ and we should help with this."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:82
+# 4cffd2fb14c64c8abca846161203f289
+msgid "Static Libraries"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:84
+# 6ccaf98902504122aa73d033cac53220
+msgid "The -dev package also ships ``usr/lib/libnova.a``.  This is a static library, an alternative to the shared library.  Any programme compiled against the static library will include the code directory into itself.  This gets round worrying about binary compatibility of the library.  However it also means that any bugs, including security issues, will not be updated along with the libary until the programme is recompiled.  For this reason programmes using static libraries are discouraged."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:94
+# 398bf230fe85495fb24337ec903082d5
+msgid "Symbol Files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:96
+# 870880e5a31c40b2a6c33ca619012e39
+msgid "When a package builds against a library the ``shlibs`` mechanism will add a package dependency on that library.  This is why most programmes will have ``Depends: ${shlibs:Depends}`` in ``debian/control``.  That gets replaced with the library dependencies at build time.  However shlibs can only make it depend on the major ABI version number, ``2`` in our libnova example, so if new symbols get added in libnova 2.1 a programme using these symbols could still be installed against libnova ABI 2.0 which would then crash."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:104
+# e6474afb8a8841ea8e5f50f6d3c97cdb
+msgid "To make the library dependencies more precise we keep ``.symbols`` files that list all the symbols in a library and the version they appeared in."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:107
+# 959ea7b001924fc0a6686b13140ea5c9
+msgid "libnova has no symbols file so we can create one.  Start by compiling the package::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:112
+# e06fccd8d4ab438a95bedf83eea74599
+msgid "The ``-nc`` will cause it to finish at the end of the compile without removing the build.  Change to the build and run ``dpkg-gensymbols`` for the library package::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:119
+# 05828480fd53405699d8ad8a89aee466
+msgid "This makes a diff file which you can self apply::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:123
+# 247935b3befb47f78155de9bf6b4a97e
+msgid "Which will create a file named similar to ``dpkg-gensymbolsnY_WWI`` that lists all the symbols.  It also lists the current package version.  We can remove the packaging version from that listed in the symbols file because new symbols are not generally added by new packaging versions::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:130
+# e6a01960a5b94448a8463cfbac6b2dd4
+msgid "Now move the file into its location, commit and do a test build::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:138
+# f14902b00f9541f3a5065bc0dac139c1
+msgid "If it successfully compiles the symbols file is correct.  With the next upstream version of libnova you would run dpkg-gensymbols again and it will give a diff to update the symbols file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:143
+# 98b9e46b70e8436cb84a7901e53db11a
+msgid "C++ Library Symbols Files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:145
+# 77dfecd2e3ca4500a800a0637fef9f7a
+msgid "C++ has even more exacting standards of binary compatibility than C.  The Debian Qt/KDE Team maintain some scripts to handle this, see their `Working with symbols files`_ page for how to use them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:150
+# b21519bcb125410b9494569ca65edef2
+msgid "Further Reading"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:152
+# cacbb05f8e934e378c081170f0d24d74
+msgid "Junichi Uekawa's `Debian Library Packaging Guide`_ goes into this topic in more detail."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:3
+# 9d2486bdfc7e487e9b8af112c9316924
+msgid "Packaging New Software"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:5
+# 59fba311ff094ebcb043d86060dd02b4
+msgid "While there are thousands of packages in the Ubuntu archive, there are still a lot nobody has gotten to yet. If there is an exciting new piece of software that you feel needs wider exposure, maybe you want to try your hand at creating a package for Ubuntu or a PPA. This guide will take you through the steps of packaging new software."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:12
+# 0aa343b58400430ea898e6d0bfd9de8d
+msgid "Checking the Programme"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:14
+# 4c0b9a06c0504ea38a1e32b0ae28ffd4
+msgid "The first stage in packaging is to get the released tar from upstream (we call the authors of applications \"upstream\") and check that it compiles and runs."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:17
+# 6c13fecc7fee401fbbdf0ec8ab90982f
+msgid "This guide will take you through packaging a simple application called KQRCode which has been `posted on KDE-apps.org`_.  Download `version 0.4 from Sourceforge`_ and put it in a new directory."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:21
+# 400f126b6d35496698950fa9a7b804a4
+msgid "Now uncompress it::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:26
+# 92f40d14bcdc4f5cafad97c347d58e0c
+msgid "This application uses the CMake build system so we want to run cmake to prepare for compilation::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:33
+# 08f8ef0e76a44a4f88c2a4d60ab6bb1f
+msgid "CMake will check for the required dependencies, in this case it tells us we need Qt and KDE libraries.  We also need GCC, packagers can install ``build-essential`` which brings this in and is assumed to be installed for all packages. If you do not have the development files for these libraries installed it will fail, you can install them and run CMake again::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:42
+# c788bb971799420e940f9317d82e574a
+msgid "Now you can compile the source::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:46
+# 9f9b99040e684a8ca7b157fa2539133b
+msgid "Running this gives some errors about missing headers.  This means there are other libraries missing which were not checked by CMake.  Make a note to inform upstream of this problem.  `packages.ubuntu.com`_ can be used to find which packages these headers come from, install these packages and continue the compile::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:55
+# d78b9316c1ee4c77852e7d26ec46b8c5
+msgid "If the compile completes successfully you can install and run the programme::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:61
+# ac725bc6291b415c8b6b6de3d9290eed
+msgid "Starting a Package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:63
+# aedb86fe4f8241a8843892eb97599ff0
+msgid "``bzr-builddeb`` includes a plugin to create a new package from a template, the plugin is a wrapper around the ``dh_make`` command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:69
+# 187e6290a2f94d9ebff13d1b65a2fa99
+msgid "When it asks what type of package type ``s`` for single binary."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:71
+# 03268a6b1a54434abb8de4bccd4391f6
+msgid "This will import the code into a branch and add the ``debian/`` packaging directory.  Have a look at the contents.  Most of the files it adds are only needed for specialist packages (such as Emacs modules) so you can start by removing the optional example files::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:79
+# 48e36e15ca254116907f8a77750fdd09
+msgid "You should now customise each of the files."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:81
+# f9ab5fc134fb4cee8e32e556a07fe586
+msgid "In ``debian/changelog`` change the version number to an Ubuntu version: ``0.4-0ubuntu1`` (upstream version 0.4, Debian version 0, Ubuntu version 1).  Also change ``unstable`` to the current development Ubuntu release such as ``oneiric``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:86
+# 68fb6f78c08c49c7aacf1a866b5c1480
+msgid "Much of the package building work is done by a series of scripts called ``debhelper``.  The exact behaviour of ``debhelper`` changes with new major versions, the compat file instructs ``debhelper`` which version to act as.  You will generally want to set this to the most recent version which is ``8``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:92
+# bf0f078ee9fe47c7a49fcc96065db39d
+msgid "``control`` contains all the metadata of the package.  The first paragraph describes the source package.  The second and and following paragraphs describe the binary packages to be built.  We will need to add the packages needed to compile the application to ``Build-Depends:`` so set that to::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:100
+# 6b883941eafb476589f23774b2b01bfc
+msgid "You will also need to fill in a description of the programme in the ``Description:`` field."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:103
+# 208710fb26b4452184d399e77c4cb867
+msgid "``copyright`` needs to be filled in to follow the licence of the upstream source.  According to the kqrcode/COPYING file this is GNU GPL 3 or later."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:106
+# 0012e8d84be04d68b3038b628e5ccbc2
+msgid "``docs`` contains any upstream documentation files you think should be included in the final package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:109
+# 756545d85bcc40c1a333e2b35f275b7b
+msgid "``README.source`` and ``README.Debian`` are only needed if your package has any non-standard features, we don't so you can delete them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:112
+# 312f3c37d8b14073a30458410e26a220
+msgid "``source/format`` can be left as is, this describes the version format of the source package and should be ``3.0 (quilt)``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:115
+# 7a915cabe45d47e996bb9a6b61cabc91
+msgid "``rules`` is the most complex file.  This is a Makefile which compiles the code and turns it into a binary package.  Fortunately most of the work is automatically done these days by ``debhelper 7`` so the universal ``%`` Makefile target just runs the ``dh`` script which will run everything needed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:120
+# a8fb1e2bc95642288d7a16a784fc733c
+msgid "Finally commit the code to your packaging branch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:125
+#: ../ubuntu-packaging-guide/udd-working.rst:69
+# d2c0b4d8d90b48b19f2c373ed55eab75
+# ecfe8d82e2114f7fb824b8b17e491ce6
+msgid "Building the package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:127
+# 0d02d6cbb00c4afd912ded7a8cbd2ae1
+msgid "Now we need to check that our packaging successfully compiles the package and builds the .deb binary package::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:132
+# 37b8625fff6b4efcba2587de14621e20
+msgid "``debuild`` is a command to build the package in its current location.  The ``-us -uc`` tell it there is not need to GPG sign the compile.  The result will be placed in ``..``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:136
+# d4b4cf3877124f738e8501904b60a80c
+msgid "You can view the contents of the package with::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:140
+# 6fc445d27f0149098cf9e27f81b0bfaa
+msgid "Install the package and check it works::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:145
+# 0b7a2d16133847e9aacff428d788ceaa
+msgid "Next Steps"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:147
+# b5d75f5868754b4596d239d6f5556d92
+msgid "Even if it builds the .deb binary package, your packaging may have bugs.  Many errors can be automatically detected by our tool ``lintian`` which can be run on both the source .dsc metadata file and the .deb binary package::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:155
+# 662bd4ddf12449c49cab0687ed1bfed7
+msgid "A description of each of the problems it reports can be found on the `lintian website`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:158
+# f20bba2b62e14567b1fbb57eb23214b4
+msgid "After making a fix to the packaging you can rebuild using ``-nc`` \"no clean\" without having to build from scratch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:163
+# 1a81beef68d64e798a6d81cccb660f4e
+msgid "Having checked that the package builds locally you should ensure it builds on a clean system using ``pbuilder``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:170
+# 17ae18ca6a564c998abd447254e188f7
+msgid "When you are happy with your package you will want others to review it.  You can upload the branch to Launchpad for review::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:175
+# 17392b1fff004e2493366c5fcadcb1c0
+msgid "Uploading it to a PPA (Personal Package Archive) will ensure it builds and give an easy way for you and others to test the binary packages. You will need to set up a PPA in Launchad then upload with ``dput``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:181
+# c8c0618209c2424d9beac381d3b024f6
+msgid "See :doc:`uploading<./udd-uploading>` for more information."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:183
+# 8ab83f0bc099482593d87bec8daf50ce
+msgid "You can ask for reviews in ``#ubuntu-motu`` IRC channel, or on the `MOTU mailing list`_.  There might also be a more specific team you could ask such as the Kubuntu team for KDE packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:188
+# 9529cb8f705547dc95d7d25c82e857f7
+msgid "Submitting for inclusion"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:190
+# 87fc979533c04e45992453914d17a982
+msgid "There are a number of paths that a package can take to enter Ubuntu. In most cases, going through Debian first can be the best path. This way ensures that your package will reach the largest number of users as it will be available in not just Debian and Ubuntu but all of their derivatives as well. Here are some useful links for submitting new packages to Debian:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:197
+# 03d85c092776496ab0969fd84fd973c7
+msgid "`Debian Mentors FAQ`_ - debian-mentors is for the mentoring of new and prospective Debian Developers. It is where you can find a sponsor to upload your package to the archive."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:201
+# be95ee15b6f840a8be29c9a24eee784c
+msgid "`Work-Needing and Prospective Packages`_ - Information on how to file \"Intent to Package\" and \"Request for Package\" bugs as well as list of open ITPs and RFPs."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:205
+# 7bfbf158bcc445d6afbdc51a8bbce4e0
+msgid "`Debian Developer's Reference, 5.1. New packages`_ - The entire document is invaluable for both Ubuntu and Debian packagers. This section documents processes for sumbitting new packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/packaging-new-software.rst:209
+# 04f7ce3e6a144369bd5a0de44748fc8f
+msgid "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 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`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:3
+# 2241baf03ca34a08b7d7e3fdda30ced7
+msgid "Patches to Packages"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:5
+# 5c3751ca50de4e1387fa501b03bf1eb5
+msgid "Sometimes, Ubuntu package maintainers have to change the upstream source code in order to make it work properly on Ubuntu.  Examples include, patches to upstream that haven't yet made it into a released version, or changes to the upstream's build system needed only for building it on Ubuntu.  We could change the upstream source code directly, but doing this makes it more difficult to remove the patches later when upstream has incorporated them, or extract the change to submit to the upstream project.  Instead, we keep these changes as separate patches, in the form of diff files."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:14
+# 1a8dc2ea6df045c791f0924de1eba7a3
+msgid "There are a number of different ways of handling patches in Debian packages, fortunately we are standardising on one system, `Quilt`_, which is now used by most packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:18
+# 36be977d3c7b4b27ac83f787d1c20ba6
+msgid "Let's look at an example package, ``kamoso`` in Natty::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:22
+# 5529f33d3d0b478fac7ea68ab8405610
+msgid "The patches are kept in ``debian/patches``.  This package has one patch ``kubuntu_01_fix_qmax_on_armel.diff`` to fix a compile failure on ARM.  The patch has been given a name to describe what it does, a number to keep the patches in order (two patches can overlap if they change the same file) and in this case the Kubuntu team adds their own prefix to show the patch comes from them rather than from Debian."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:29
+# e635b7e963bb4caeac48400b23c7811f
+msgid "The order of patches to apply is kept in ``debian/patches/series``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:32
+# b694697d5a60411bb2c7dc37ed4675f0
+msgid "Patches with Quilt"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:34
+# 6bb7b69eac2346bf980295dbddc298c4
+msgid "Before working with Quilt you need to tell it where to find the patches.  Add this to your ``~/.bashrc``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:39
+# cbac6263b89f4e62bcfae1a183202ab1
+msgid "And source the file to apply the new export::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:43
+# 90e75b21038b415cb7124b81a3119dd0
+msgid "By default all patches are applied already to UDD checkouts or downloaded packages.  You can check this with::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:49
+# d4faacee0f964e4a9beebcae8a1def6f
+msgid "If you wanted to remove the patch you would run ``pop``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:57
+# 7d2578ea2fb3424ba9f76dfb56642311
+msgid "And to apply a patch you use ``push``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:67
+# 3920a9d86b834234be836b63f21ab810
+msgid "Adding a New Patch"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:69
+# fb390d3c3be349cdb600350811c9671d
+msgid "To add a new patch you need to tell Quilt to create a new patch, tell it which files that patch should change, edit the files then refresh the patch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:81
+# 9041df0abe5140678fe386d7d4b9b92c
+msgid "The ``quilt add`` step is important, if you forget it the files will not end up in the patch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:84
+# 9e80030f1eb6438a9bc24959f9cfac5d
+msgid "The change will now be in ``debian/patches/kubuntu_02_programme_description.diff`` and the ``series`` file will have had the new patch added to it.  You should add the new file to the packaging::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:94
+# 6f36a309febe4b4b83ff777007dc4901
+msgid "Quilt keeps its metadata in the ``.pc/`` directory, so currently you need to add that to the packaging too.  This should be improved in future."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:97
+# c25ed33cbb694bb5ab2fd2719f11adef
+msgid "As a general rule you should be careful adding patches to programmes unless they come from upstream, there is often a good reason why that change has not already been made.  The above example changes a user interface string for example, so it would break all translations.  If in doubt, do ask the upstream author before adding a patch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:104
+# a9bcd232fe19471a8dd3bc40ac48ec2a
+msgid "Upgrading to New Upstream Versions"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:106
+# df088161eeb042c1a7a74ac49eaa923b
+msgid "When you upgrade to a new upstream version, patches will often become out of date.  They might need to be refreshed to match the new upstream source or they might need to be removed altogether."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:110
+# 870e3c1c96724cc1a4f9ca814cddf71b
+msgid "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`_::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:116
+# 01d84a0499414f2a8f7e73acf0c14f58
+msgid "Then upgrade to the new version"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:118
+# 060a7d5c6b1e42a2bdfe566bd96e126d
+msgid "$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:120
+# 61de3ecb174b44daa1ef323e29f1b9da
+msgid "Then apply the patches one at a time to check for problems::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:129
+# 5d35e1273bbd4487a49ec82a1dd0607b
+msgid "If it can be reverse-applied this means the patch has been applied already by upstream, so we can delete the patch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:135
+# b0bfdc2a871f47538cdc0d72eaab11d4
+msgid "Then carry on::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:140
+# eb92e1c67e134b738c41bec49059cc7c
+msgid "It is a good idea to run refresh, this will update the patch relative to the changed upstream source::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:146
+# 8ad4cf528b9d4543b6a610c13ffdd227
+msgid "Then commit as usual::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:152
+# 6f2cbc44cb544b2ebdfe54bda2edb7fc
+msgid "Making A Package Use Quilt"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:154
+# 6ca7a58987bb496face3eacc1bfb6f78
+msgid "Modern packages use Quilt by default, it is built into the packaging format.  Check in ``debian/source/format`` to ensure it says ``3.0 (quilt)``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:158
+# e49e867c8e604b53a561bf92af15f40e
+msgid "Older packages using source format 1.0 will need to explicitly use Quilt, usually by including a makefile into ``debian/rules``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:163
+# d91974b6f93a4ebc83b3ebdff6a5d578
+msgid "Other Patch Systems"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:165
+# 95e9287c4e5b4d8eb3aebe3f6f3342e3
+msgid "Other patch systems used by packages include ``dpatch`` and ``cdbs simple-patchsys``, these work similarly to Quilt by keeping patches in debian/patches but have different commands to apply, unapply or create patches. You can use ``edit-patch``, shown in previous chapters, as a reliable way to work with all systems."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:171
+# f38c643c88ec478f8dffd3c0b3b6107b
+msgid "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 versions or differentiate between patches and is best avoided."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:175
+# 9520c1dcd3714fcbb7cd1a4123db0488
+msgid "Bazaar Loom is a way to keep patches as part of bzr trees, see :doc:`Working with Patches via Loom<./udd-patchsys>` for more information."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/patches-to-packages.rst:178
+# 44bb230bde8243e88d02160fafeb25e1
+msgid "Do not change a package's patch system without discussing it with the Debian maintainer or relevant Ubuntu team.  If there is no existing patch system then feel free to add Quilt."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:3
+# fcaa66fc4d6e4c70a68f6edce85a973f
+msgid "Security and Stable Release Updates"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:6
+# 44937136520b417ab88d6f9dca66a583
+msgid "Fixing a Security Bug in Ubuntu"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:11
+# 6ea8baeb570c49fe81e30b93b0106a86
+msgid "Fixing security bugs in Ubuntu is not really any different than :doc:`fixing a regular bug in Ubuntu<./fixing-a-bug>`, and it is assumed that you are familiar with patching normal bugs. To demonstrate where things are different, we will be updating the dbus package in Ubuntu 10.04 LTS (Lucid Lynx) for a security update."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:19
+# b2012d850e594307ab0fc8ff75da7070
+msgid "Obtaining the source"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:21
+# 50cca424f3334607971cf3b684408134
+msgid "In this example, we already know we want to fix the dbus package in Ubuntu 10.04 LTS (Lucid Lynx). So first you need to determine the version of the package you want to download. We can use the ``rmadison`` to help with this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:30
+# 160e2724f58a49d29b12dc794073fce9
+msgid "Typically you will want to choose the highest version for the release you want to patch that is not in -proposed or -backports. Since we are updating Lucid's dbus, you'll download 1.2.16-2ubuntu4.2 from lucid-updates::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:38
+# f1c7e672c4d04f32bf8fd5455422f789
+msgid "Patching the source"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:39
+# 69bcfabad54d4339bef655df9d2b1001
+msgid "Now that we have the source package, we need to patch it to fix the vulnerability. You may use whatever patch method that is appropriate for the package, including :doc:`UDD techniques<./udd-intro>`, but this example will use ``edit-patch`` (from the ubuntu-dev-tools package). ``edit-patch`` is the easiest way to patch packages and it is basically a wrapper around every other patch system you can imagine."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:46
+# e3377b23d7a547cdaabdf4606ad86234
+msgid "To create your patch using ``edit-patch``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:51
+# ea53b2134aae47fb9c41c935c1c14647
+msgid "This will apply the existing patches and put the packaging in a temporary directory. Now edit the files needed to fix the vulnerability.  Often upstream will have provided a patch so you can apply that patch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:57
+# c8f4bfe3fbd94f54b2efdee70bd8ecdd
+msgid "Aftering making the necessary changes, you just hit Ctrl-D or type exit to leave the temporary shell."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:61
+# 3ab2cb5e96cf425c8bb62d682dfb5bef
+msgid "Formatting the changelog and patches"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:63
+# 32cf2e90495e499a88a886c1bbecc26e
+msgid "After applying your patches you will want to update the changelog. The ``dch`` command is used to edit the ``debian/changelog`` file and ``edit-patch`` will launch ``dch`` automatically after unapplying all the patches. If you are not using ``edit-patch``, you can launch ``dch -i`` manually. Unlike with regular patches, you should use the following format (note the distribution name uses lucid-security since this is a security update for Lucid) for security updates::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:80
+# ed919cc67ea9442dac459f1cc3d64aeb
+msgid "Update your patch to use the appropriate patch tags. Your patch should have at a minimum the Origin, Description and Bug-Ubuntu tags. For example, edit debian/patches/99-fix-a-vulnerability.patch to have something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:91
+# 8e0fc3aa272a4b3baf5f4d3c43643d02
+msgid "Multiple vulnerabilities can be fixed in the same security upload; just be sure to use different patches for different vulnerabilities."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:95
+# 814ea189399a4700901458d9e274c17a
+msgid "Test and Submit your work"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:97
+# f8623540f61643408dee80d6a8d176ab
+msgid "At this point the process is the same as for :doc:`fixing a regular bug in Ubuntu<./fixing-a-bug>`. Specifically, you will want to:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:100
+# a594d5cc105044b79b691029f7176bb4
+msgid "Build your package and verify that it compiles without error and without any added compiler warnings"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:102
+# 8a246f8802e2464693909bfa93b85323
+msgid "Upgrade to the new version of the package from the previous version"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:103
+# 98467e4df61c444a90c17dada9ab0428
+msgid "Test that the new package fixes the vulnerability and does not introduce any regressions"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:105
+# fd79f702d89e41cd8a66e6c26cfd3cf9
+msgid "Submit your work via a Launchpad merge proposal and file a Launchpad bug being sure to mark the bug as a security bug and to subscribe ``ubuntu-security-sponsors``"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:109
+# 3aee8769d59e4288b13ee8d4f9279cd4
+msgid "If the security vulnerability is not yet public then do not file a merge proposal and ensure you mark the bug as private."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:112
+# 4454e4ec4d504a989350286c1dc011a3
+msgid "The filed bug should include a Test Case, i.e. a comment which clearly shows how to recreate the bug by running the old version then how to ensure the bug no longer exists in the new version."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:116
+# 0ed66335fe214b25b3a214779fa79b47
+msgid "The bug report should also confirm that the issue is fixed in Ubuntu versions newer than the one with the proposed fix (in the above example newer than Lucid).  If the issue is not fixed in newer Ubuntu versions you should prepare updates for those versions too."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:123
+# 9d58c76584ab422aad579dc066f350e9
+msgid "Stable Release Updates"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:125
+# b8c8cef56aa84c5683332a6a4ca34e9d
+msgid "We also allow updates to releases where a package has a high impact bug such as a severe regression from a previous release or a bug which could cause data loss.  Due to the potential for such updates to themselves introduce bugs we only allow this where the change can be easily understood and verified."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:130
+# 17790d066b284657a6f8573eb0a33a12
+msgid "The process for Stable Release Updates is just the same as the proccess for security bugs except you should subscribe ``ubuntu-sru`` to the bug."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:133
+# 81a7322879ab43249b9d1cd8a24b8616
+msgid "The update will go into the ``proposed`` archive (for example ``lucid-proposed``) where it will need to be checked that it fixes the problem and does not introduce new problems.  After a week without reported problems it can be moved to ``updates``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:138
+# f654430d35904327bb2a7b6ce0a9d903
+msgid "See the `Stable Release Updates wiki page`_ for more information."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/traditional-packaging.rst:3
+# 01e146ed20574b0491518a5fa96a7814
+msgid "Traditional Packaging"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/traditional-packaging.rst:5
+# bfc81f2a439f41328fa57d85524df487
+msgid "FIXME describe traditional packaging here"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:3
+# de45b250ee434651b8ba2943337e2d9e
+msgid "Getting the Source"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:6
+# 708a4d932f37463e9fe6c0a5064dada9
+msgid "Source package URLs"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:8
+# 1377317bd9494ced9d4a0891bee7a957
+msgid "Bazaar provides some very nice shortcuts for accessing Launchpad's source branches of packages in both Ubuntu and Debian."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:11
+# 170a9600a8f44caeae10765baaf7c21f
+msgid "To refer to source branches use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:15
+# 1d24fcdc74354dd7bff584230dfea113
+msgid "where *package* refers to the package name you're interested in.  This URL refers to the package in the current development version of Ubuntu.  To refer to the branch of Tomboy in the development version, you would use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:21
+# 7d357984ada0447ba0431181a58b5075
+msgid "To refer to the version of a source package in an older release of Ubuntu, just prefix the package name with the release's code name.  E.g. to refer to Tomboy's source package in Maverick_ use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:27
+# 403064151cb24c388caca162735fa0bb
+msgid "Since they are unique, you can also abbreviate the distro-series name::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:31
+# 262e6ccf32c64d649061db02ab0e5f12
+msgid "You can use a similar scheme to access the source branches in Debian, although there are no shortcuts for the Debian distro-series names.  To access the Tomboy branch in the current development series for Debian use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:37
+# 0ceef9271de640e28199e83e7a349385
+msgid "and to access Tomboy in Debian Lenny_ use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:48
+# e728f15a7ae54e96b3c8999fb3940624
+msgid "Getting the source"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:50
+# a67d179daf624f7dbbaf3eedfcbcaf6b
+msgid "Every source package in Ubuntu has an associated source branch on Launchpad. These source branches are updated automatically by Launchpad, although the process is not currently foolproof."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:54
+# 50f77ec3e33946019d79cf8f8e68c980
+msgid "There are a couple of things that we do first in order to make the workflow more efficient later.  Once you are used to the process you will learn when it makes sense to skip these steps."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:62
+# 811a02ac0bb74e139dcc5e7d10dc3de2
+msgid "Creating a shared repository"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:64
+# ea541ef4f3bc44c7808d29301195de53
+msgid "You want to work on the Tomboy package in Natty, and you've verified that the source package is named ``tomboy``.  Before actually branching the code for Tomboy, create a shared repository to hold the branches for this package.  The shared repository will make future work much more efficient."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:70
+# a93654da2b2842c3883bd62ee844cf65
+msgid "Do this using the `bzr init-repo` command, passing it the directory name we would like to use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:75
+# 6ac6ea4044af40e69f14be43ecd8e313
+msgid "You will see that a `tomboy` directory is created in your current working area.  Change to this new directory for the rest of your work::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:82
+# e26beb7d28ab4c29ab4f6f4e4c609347
+msgid "Getting the trunk branch"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:84
+# 9c8b09e39fa544619be271049b65feb3
+msgid "We use the `bzr branch` command to create a local branch of the package. We'll name the target directory `tomboy.dev` just to keep things easy to remember::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:90
+# 1c098b0aedf040e9896f809d48da7baf
+msgid "The tomboy.dev directory represents the version of Tomboy in the development version of Ubuntu, and you can always ``cd`` into this directory and do a `bzr pull` to get any future updates."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:97
+# 478330b59866411d9ac4d2b636845be3
+msgid "Ensuring the version is up to date"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:99
+# d3d9360875864092acc72d83fec79552
+msgid "When you do your ``bzr branch`` you will get a message telling you if the packaging branch is up to date.  For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:107
+# 46fe13c7e5414876b713f54610679084
+msgid "Occasionally the importer fails and packaging branches do not match what is in the archive.  A message saying::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:112
+# 61d9a5892a464d35bd5b53cd3475ced0
+msgid "means the importer has failed.  You can find out why on http://package-import.ubuntu.com/status/ and `file a bug on the UDD project`_ to get the issue resolved."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:118
+# e29e16998b494544859ca798910a447a
+msgid "Upstream Tar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:120
+# 20386da53a3741a4a7b84b07b6f0415b
+msgid "You can get the upstream tar by running::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:124
+# a8dd0f34885b4a9a87be2aa44d7d1c6a
+msgid "This will try a number of methods to get the upstream tar, firstly by recreating it from the ``upstream-x.y`` tag in the bzr archive, then by downloading from the Ubuntu archive, lastly by running ``debian/rules get-orig-source``. The upstream tar will also be recreated when using bzr to build the package::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:132
+# f92e4efcc80749d4a2d194c830a44e04
+msgid "The `builddeb` plugin has several `configuration options`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:136
+# 1549cda4ab0f4671921760913c600e9d
+msgid "Getting a branch for a particular release"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:138
+# 5e1d5d3463784729b51804337afd0f15
+msgid "When you want to do something like a `stable release update`_ (SRU), or you just want to examine the code in an old release, you'll want to grab the branch corresponding to a particular Ubuntu release.  For example, to get the Tomboy package for Maverick do::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:147
+# 89b049dc5a4e4ab4a5d79fba7de14a97
+msgid "Importing a Debian source package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:149
+# 948574e1256b401c845dbde95388ad7a
+msgid "If the package you want to work on is available in Debian but not Ubuntu, it's still easy to import the code to a local bzr branch for development.  Let's say you want to import the `newpackage` source package.  We'll start by creating a shared repository as normal, but we also have to create a working tree to which the source package will be imported (remember to cd out of the `tomboy` directory created above)::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-getting-the-source.rst:162
+# 68b9d2904b2042c8a2feeca5b2112463
+msgid "As you can see, we just need to provide the remote location of the dsc file, and Bazaar will do the rest.  You've now got a Bazaar source branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:3
+# e02e5ddbac284aa99584a94dd0782d6e
+msgid "Ubuntu Distributed Development - Introduction"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:5
+# 7ee4234b07754d448c2002b58fcf0a5a
+msgid "This guide focuses on packaging using the *Ubuntu Distributed Development* (UDD) method."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:8
+# f06705abe97045758ae653af62eab8a6
+msgid "*Ubuntu Distributed Development* (UDD) is a new technique for developing Ubuntu packages that uses tools, processes, and workflows similar to generic distributed version control system (DVCS) based software development.  The DVCS used for UDD is Bazaar_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:14
+# dc7215466a424301828c9e3bcde1a22f
+msgid "Traditional Packaging Limitations"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:16
+# 371cfc21d714497ab868f5e1854d61ef
+msgid "Traditionally Ubuntu packages have been kept in tar archive files.  A traditional source package is made up of the upstream source tar, a \"debian\" tar (or compressed diff file for older packages) containing the packaging and a .dsc meta-data file.  To see a traditional package run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:23
+# 1aadf41ee8ef444083f2dea4ad45ec67
+msgid "This will download the upstream source ``kdetoys_4.6.5.orig.tar.bz2``, the packaging ``kdetoys_4.6.5-0ubuntu1.debian.tar.gz`` and the meta-data ``kdetoys_4.6.5-0ubuntu1~ppa1.dsc``.  Assuming you have dpkg-dev installed it will extract these and give you the source package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:28
+# cf162dd8ac104619800b05a4e8706935
+msgid "Traditional packaging would edit these files and upload.  However this gives limited opportunity to collaborate with other developers, changes have to be passed around as diff files with no central way to track them and two developers can not make changes at the same time.  So most teams have moved to putting their packaging in a revision control system.  This makes it easier for several developers to work on a package together.  However there is no direct connection between the revision control system and the archive packages so the two must be manually kept in sync.  Since each team works in its own revision control system a prospective developer must first work out where that is and how to get the packaging before they can work on the package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:40
+# ae01db626fea46f78e6cd18691596898
+msgid "Ubuntu Distributed Development"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:42
+# 974d49485a2849168e9942b0804aa69e
+msgid "With Ubuntu Distributed Development all packages in the Ubuntu (and Debian) archive are automatically imported into Bazaar branches on our code hosting site Launchpad.  Changes can be made directly to these branches in incremental steps and by anyone with commit access.  Changes can also be made in forked branched and merged back in with Merge Proposals when they are large enough to need review or if they are by someone without direct commit access."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:49
+# 2af22c6ccf5947babf7cc5902e40e461
+msgid "UDD branches are all in a standard location so doing a checkout is easy::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:53
+# cb5e2ec745b64f1693c487a5cf6e4bbd
+msgid "The merge history includes two separate branches, one for the upstream source and one which adds the ``debian/`` packaging directory::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:59
+# 1054f464b56142dab7d1a8e336bda0a4
+msgid "(This command uses *qbzr* for a GUI, run ``log`` instead of ``qlog`` for console output.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:64
+# 1dab11a12fd74a3c9b6b0381b1097201
+msgid "This UDD branch of *kdetoys* shows the full packaging for each version uploaded to Ubuntu with grey circles and the upstream source versions with green circles.  Versions are tagged with either the version in Ubuntu such as ``4:4.2.29-0ubuntu1`` or for the upstream branch with the upstream version ``upstream-4.2.96``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:70
+# bc572117cad0476eb5548602d8dec778
+msgid "Many Ubuntu packages are based on the packages in Debian, UDD also imports the Debian package into our branches.  In the *kdetoys* branch above the Debian versions from *unstable* are from the merge with blue circles while those from *Debian experimental* are from the merge with yellow circles.  Debian released are tagged with their version number e.g. ``4:4.2.2-1``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:76
+# dacd0f46f92a406c86b2679ce3bf4e28
+msgid "So from a UDD branch you can see the complete history of changes to the package and compare any two versions.  For example, to see the changes between version 4.2.2 in Debian and the 4.2.2 in Ubuntu use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:82
+# d71b4d03fccb4e2680449bdc9fa8669b
+msgid "(This command uses *qbzr* for a GUI, run ``diff`` instead of ``qdiff`` for console output.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:87
+# 208d833fb66e44b7b0ac5a51f0e6d6ef
+msgid "From this we can clearly see what has changed in Ubuntu compared to Debian, very handy."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:91
+# ae15adc6961442969d8f05f291313348
+msgid "Bazaar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:93
+# 25ba427a878d451eb0d6bcf63ee5ce00
+msgid "UDD branches use Bazaar, a distributed revision control system intended to be easy to use for those familiar with popular systems such as Subversion while offering the power of Git."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:97
+# f0cefb6f5b3a485aa4e7f7e1819e7cdf
+msgid "To do packaging with UDD you will need to know the basics of how to use Bazaar to manage files.  For an introduction to Bazaar see the `Bazaar Five Minute Tutorial <http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html>`_ and the `Bazaar Users Guide <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html>`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:105
+# c08d41d2e3c94aebb87744586cee7534
+msgid "Limitations of UDD"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:107
+# adf0a0ae209340c592c8159ca0f14d66
+msgid "Ubuntu Distributed Development is a new method for working with Ubuntu packages.  It currently has some notable limitations:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:110
+# 74f68a68c767479c89d3d0ee9396c90f
+msgid "Doing a full branch with history can take a lot of time and network resources.  You may find it quicker to do a lightweight checkout ``bzr checkout --lightweight ubuntu:kdetoys`` but this will need a network access for any further bzr operations."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:115
+# 4cbeca18d43241faa9c2c1e3817ffa90
+msgid "Working with patches is fiddly.  Patches can be seen as a branched revision control system, so we end up with RCS on top of RCS."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:118
+# 7b4d6c271a8d45f5bac7e40ebff32612
+msgid "There is no way to build directly from branches.  You need to create a source package and upload that."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:121
+# 270ea10b5b5940219b098bfc706f4d40
+msgid "Some packages have not been successfully imported into UDD branches.  Recent versions of Bazaar will automatically notify you when this is the case. You can also check the `status of the package importer`_ manually before working on a branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-intro.rst:126
+# 3bb30727b0e849be88b4583d071b56d3
+msgid "All of the above are being worked on and UDD is expected to become the main way to work on Ubuntu packages soon.  However currently most teams within Ubuntu do not yet work with UDD branches for their  development.  However because UDD branches are the same as the packages in the  archive any team should be able to accept merges against them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:3
+# 9d1a300c3d9345369085e904b67313c1
+msgid "Getting The Latest"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:5
+# 339c0245957f4160b0005b947a3e0d49
+msgid "If someone else has landed changes on a package, you will want to pull those changes in your own copies of the package branches."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:10
+# c18361aeed4245cab2688e479f43a4eb
+msgid "Updating your main branch"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:12
+# a3d5cd0913d04caabf195aeb2cda64c4
+msgid "Updating your copy of a branch that corresponds to the package in a particular release is very simple, simply use `bzr pull` from the appropriate directory::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:18
+# 575912a50bdb4bc2ab0148d8acfb7535
+msgid "This works wherever you have a checkout of a branch, so it will work for things like branches of `maverick`, `hardy-proposed`, etc."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:23
+# 715c9c2a3372432babab101922e160f8
+msgid "Getting the latest in to your working branches"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:25
+# e4fcfc4c42594affae741d5a17617daf
+msgid "Once you have updated your copy of a distroseries branch, then you may want to merge this in to your working branches as well, so that they are based on the latest code."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:29
+# 55c9366ed7bb49f7b149db6445b466bc
+msgid "You don't have to do this all the time though.  You can work on slightly older code with no problems.  The disadvantage would come if you were working on some code that someone else changed.  If you are not working on the latest version then your changes may not be correct, and may even produce conflicts."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:34
+# 69a77acb1eb54553bc5dcd9c3d08a871
+msgid "The merge does have to be done at some point though.  The longer it is left, the harder may be, so doing it regularly should keep each merge simple.  Even if there are many merges the total effort would hopefully be less."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:38
+# eef9b9378c9b45838c22b8f4773953c5
+msgid "To merge the changes you just need to use ``bzr merge``, but you must have committed your current work first::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:44
+# 3edc5b6354f848f4b32613cde5118ac9
+msgid "Any conflicts will be reported, and you can fix them up.  To review the changes that you just merged use ``bzr diff``.  To undo the merge use ``bzr revert``.  Once you are happy with the changes then use ``bzr commit``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:50
+# 21afeaadd6df4d46ba383135caa1d5a5
+msgid "Referring to versions of a package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:52
+# f680cb9690844d4e8d5cf6456ebb4348
+msgid "You will often think in terms of versions of a package, rather than the underlying Bazaar revision numbers.  `bzr-builddeb` provides a revision specifier that makes this convenient.  Any command that takes a ``-r`` argument to specify a revision or revision range will work with this specifier, e.g. ``bzr log``, ``bzr diff``, and so on.  To view the versions of a package, use the ``package:`` specifier::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-latest.rst:61
+# c52b8e18c3ac403c97a547b08b53b4d6
+msgid "This shows you the difference between package version 0.1-1 and 0.1-2."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:3
+# dc68e05842b14b3abc7d029142195608
+msgid "Merging - Updating from Debian and Upstream"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:5
+# 3f98d76a08334a3ba6086f2cc533d3e4
+msgid "Merging is one of the strengths of Bazaar, and something we do often in Ubuntu development.  Updates can be merged from Debian, from a new upstream release, and from other Ubuntu developers.  Doing it in Bazaar is pretty simple, and all based around the ``bzr merge`` command [#]_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:10
+# a21a2c24adf84561899031d40cee0f7e
+msgid "While you are in any branch's working directory, you can merge in a branch from a different location.  First check that you have no uncommitted changes::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:15
+# 0e0a11b7d1434c9ab7fc02be50311ba1
+msgid "If that reports anything then you will either have to commit the changes, revert them, or shelve them to come back to later."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:20
+# 30562ac2599a48a09b26b05d6de6baa6
+msgid "Merging from Debian"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:22
+# 4afeb333b11b413d8b0aaaa4bf51ed3f
+msgid "Next run ``bzr merge`` passing the URL of the branch to merge from.  For example, to merge from the version of the package in Debian Squeeze_ run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:27
+# bb6d2b7b4af740fd8421f9de5170ff16
+msgid "This will merge the changes since the last merge point and leave you with changes to review.  This may cause some conflicts.  You can see everything that the ``merge`` command did by running::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:34
+# 6ee5bb94d7304d97b2dfcec95e70dcd9
+msgid "If conflicts are reported then you need to edit those files to make them look how they should, removing the *conflict markers*.  Once you have done this, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:41
+# 8facda931138401d9d746d6cbfdf8cff
+msgid "This will resolve any conflicted files that you fixed, and then tell you what else you have to deal with."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:44
+# 37232a75c2d64e788788e8d3c9cbdcfd
+msgid "Once any conflicts are resolved, and you have made any other changes that you need, you will add a new changelog entry, and commit::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:50
+# 4d14975e51ae4c27ac3ae6b461b69c8d
+msgid "as described earlier."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:52
+# f1f7aa3a73ba40f29456f5de9273d269
+msgid "However, before you commit, it is always a good thing to check all the Ubuntu changes by running::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:57
+# 9092dbac4b564f63885a506f41582d51
+msgid "which will show the differences between the Debian (0.6.10-5) and Ubuntu versions (0.6.10-5ubuntu1).  In similar way you can compare to any other versions.  To see all available versions run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:63
+# d79b9b8fe0324043845b29278e565bce
+msgid "After testing and committing the merge, you will need to seek sponsorship or upload to the archive in the normal way."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:66
+# 19eca11f7f7a4c49a9dffa97507b559e
+msgid "If you are going to build the source package from this merged branch, you would use the ``-S`` option to the ``bd`` command.  One other thing you'll want to consider is also using the ``--package-merge`` option.  This will add the appropriate ``-v`` and ``-sa`` options to the source package so that all the changelog entries since the last Ubuntu change will be included in your ``_source.changes`` file.  For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:77
+# e3d88b2d11f54e8f848d128cdcfbc928
+msgid "Merging a new upstream version"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:79
+# 099bfde19f2041ef82ac880fb89a7656
+msgid "When upstream releases a new version (or you want to package a snapshot), you have to merge a tarball into your branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:82
+# ca21132b09dd42f6bae10b7be5d30595
+msgid "This is done using the ``bzr merge-upstream`` command.  If your package has a valid ``debian/watch`` file, from inside the branch that you want to merge to, just type this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:88
+# 56b3c9414eb44d2991f7b0d92d00f373
+msgid "This will download the tarball and merge it into your branch, automatically adding a ``debian/changelog`` entry for you.  ``bzr-builddeb`` looks at the ``debian/watch`` file for the upstream tarball location."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:92
+# 5b6202491b164f509bdb9b99311fcf3d
+msgid "If you do *not* have a ``debian/watch`` file, you'll need to specify the location of the upstream tarball, and the version manually::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:97
+# 53db9d767eca4e80ba838d2b78832063
+msgid "The ``--version`` option is used to specify the upstream version that is being merged in, as the command isn't able to infer that (yet)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:100
+# deda3c9c46464074b40bfa7a04c15155
+msgid "The last parameter is the location of the tarball that you are upgrading to; this can either be a local filesystem path, or a http, ftp, sftp, etc. URI as shown.  The command will automatically download the tarball for you.  The tarball will be renamed appropriately and, if required, converted to ``.gz``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:105
+# a8a8873c3b9745318bdaf72cd43d01e6
+msgid "The `merge-upstream` command will either tell you that it completed successfully, or that there were conflicts.  Either way you will be able to review the changes before committing as normal."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:109
+# 90b4d273a547482c9c5ecd37bdcc836d
+msgid "If you are merging an upstream release into an existing Bazaar branch that has not previously used the UDD layout, ``bzr merge-upstream`` will fail with an error that the tag for the previous upstream version is not available; the merge can't be completed without knowing what base version to merge against. To work around this, create a tag in your existing repository for the last upstream version present there; e.g., if the last Ubuntu release was *1.1-0ubuntu3*, create the tag *upstream-1.1* pointing to the bzr revision you want to use as the tip of the upstream branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-merging.rst:122
+# 010017a3c74341108012280452144e2d
+msgid "You will need newer versions of ``bzr`` and the ``bzr-builddeb`` for the ``merge`` command to work.  Use the versions from Ubuntu 12.04 (Precise) or the development versions from the ``bzr`` PPA.  Specifically, you need ``bzr`` version 2.5 beta 5 or newer, and ``bzr-builddeb`` version 2.8.1 or newer.  For older versions, use the ``bzr merge-package`` command instead."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:3
+# b8687b8342d4484381ab0009d7571faf
+msgid "Building a new package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:5
+# da3d76bf462b4fd28237be3b02d73c47
+msgid "Let's say I have an upstream project that is not yet available for Ubuntu.  I want to create a package from this project and make it available as a PPA_ so that other people can more easily use the code.  This also makes a good first step in contributing your package to universe_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:12
+# 900f00a174714536a096ade529c569ac
+msgid "Example package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:14
+# feeb33594e7442ed8e558be19bc3e7f5
+msgid "I started with a Python library called `flufl.enum`_, which is a fairly typical setuptools-based Python package.  Fortunately, it's also maintained in Launchpad using Bazaar, so that makes bootstrapping much easier."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:18
+# f765bafb78864679b1059e3f15db3a0d
+msgid "Because we want to package the trunk branch, getting started is pretty simple::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:31
+# 39a9d3352730400c808925727ac7d6c5
+msgid "Bootstrapping"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:33
+# b1ce6212d91948cfbb6f9bedfa2877c7
+msgid "You need to create the initial ``debian`` directory, as well as the necessary files inside the ``debian`` directory.  Currently, there are many ways to set up this directory, but hopefully there will be `some convergence`_ in the methods, especially if you're building standard Python setuptools-based libraries and applications."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:43
+# f87c0194eae54e80964fc3c92f512a2b
+msgid "The bzr-builddeb way"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:45
+# 940940706e2c4f2e84b92c940d147915
+msgid "You could use the ``dh_make`` command to get things going, or similarly the ``bzr dh-make``.  The latter might provide some benefits, and can be run like so from inside your branch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:52
+# b5d07b47aa6a4743b10c5da608ed31e7
+msgid "If you don't have a URL to download a tarball from, you'll need to create the tarball locally first.  Use ``bzr dh-make --help`` for details on this command."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:55
+# ad64e2f4ef1d4cd6b7a9cb18b35afe96
+msgid "After you've created the ``debian`` directory template, be sure to ``bzr rm`` any ``debian`` files you don't need (e.g. the ``*.ex`` files), and edit files such as ``debian/control``, ``debian/watch``, ``debian/copyright`` and ``debian/changelog``.  The following section may give you some hints about that."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:63
+# 1ba898157b814592a161633f29a60663
+msgid "The stdeb way"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:65
+# b1184b49f04442a3a80709e934d63205
+msgid "Another way for creating the initial ``debian`` directory for Python setuptools-based packages, is to use the stdeb_ package.  The full documentation for this package is available on the `upstream home`_, but you won't need all of the commands.  stdeb has a command that is *exactly* what we're looking for!"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:71
+# 7565c365c47b4e63b4301d873d7269ae
+msgid "In either case, start by putting this in your ``~/.pydistutils.cfg`` file::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:78
+# 13b8f0432f434c3cad4a07f63df7bc5d
+msgid "Modern stdeb"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:80
+# 4a75fbc5a4774bd4a0a03ba0e13f0c62
+msgid "Here's how easy it is::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:86
+# fa8392053d014f42b7e82ec702b7466f
+msgid "We also need a ``debian/copyright`` file.  Normally, we'd use ``dh_make -c`` for that but again, that doesn't play nicely with UDD.  ``dh_make`` expects a particular file system layout that we don't have.  No matter, we'll add the copyright file manually::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:98
+# 83c9385cd7e44dbcbad56c6dc64b116d
+msgid "stdeb <= 0.5.1"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:100
+# adb471ff8471413ba7f3702a77ff1c4a
+msgid "If you have an older version of stdeb, use this command to create the basic ``debian/`` directory layout::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:105
+# 442e744568aa4afdba53c9ac58e992ec
+msgid "This command leaves you with a ``deb_dist`` directory containing a ``flufl.enum_3.0.1`` directory.  Inside that is your ``debian/`` directory. Because we're using UDD we don't care about anything else that ``sdist_dsc`` produces, so we can shuffle things around and remove the cruft."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:110
+# a9095a611011467283d8b1e16ad71cde
+msgid "$ mv deb_dist/munepy-2.0.1/debian . $ rm -rf deb_dist $ bzr add debian $ bzr commit -m'Add debian directory'"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:117
+# d84805c6b2ff43d1815ed48cd6561ca1
+msgid "pkgme"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:119
+# e397d168c1464148a5e29252e0c05116
+msgid "pkgme_ is a new tool that makes it easy to Debianize a new package.  TBD: describe how to use it."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:124
+# 355c0182eaad4d768364d1dc84933f38
+msgid "debian/control file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:126
+# 09b6bf2c91584bec9c9eb829f34241bd
+msgid "You probably want to edit the ``debian/control`` file at this point, adding any information that's missing, or fixing incorrect default information.  For example, I needed to modify the ``Maintainer`` and ``Description`` fields, and add ``X-Python-Version`` and ``Homepage`` fields."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:131
+# 631a463946764d31afd3cdeee7d37d37
+msgid "Now we want to build the source package.  The easiest way to do that is with the ``bzr-builddeb`` plugin, however this requires a valid ``debian/watch`` file so that builddeb can find the upstream tarball.  This really should match the version of the checkout you've made."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:138
+# 9fe80612b0f241069d9c6c1eeadce841
+msgid "debian/watch file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:140
+# a718657059c940a6a3c66efda75eb96d
+msgid "Here for example is the ``debian/watch`` file I'm using::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:145
+# d553ecdd289b46feb5bb770b10486af5
+msgid "If your tarballs live on Launchpad, the ``debian/watch`` file is a little more complicated (see `Question 21146`_ and `Bug 231797`_ for why this is).  In that case, use something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:152
+# 418bf4f02fac439d998f992dbe976a8a
+msgid "So, then it's a matter of...::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:159
+# c12649f825014fe483b750d0c8964490
+msgid "Building the source package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-newpackage.rst:161
+# a94c3b29dc50469598d0f49d695c5165
+msgid "Now we can build the source package and publish the package as we normally would, with ``bzr builddeb -S`` and ``dput``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:3
+# f6fb6d9a352d4554abbeb9b2e3acefd9
+msgid "Working with Patches"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:5
+# 0363d3d4f8bf4c7b8e08d01edaf97bad
+msgid "Many existing packages that have changes from upstream express those changes using a patch system, of which there are several to choose from.  Usually, when you make an additional change to a package, you'll want to add a patch file to the patch system being used, rather than editing the source code in place.  Note however that it is considered bad practice to add a patch system to a package that does not already have one.  In that case, either coordinate with the Debian maintainer, or edit the files in place.  You can find out if your package has a patch system by using the ``what-patch`` command (from the ``ubuntu-dev-tools`` package)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:15
+# fd42ca6b29c546b1b484b212fd15fd1c
+msgid "While Debian has several patch systems, Quilt_ is becoming the most popular. Quilt acts something like a version control system itself, and in the context of UDD, this can be both a good thing and a bad thing.  With Bazaar 2.5 and ``bzr-builddeb`` 2.8.1 (in Ubuntu 12.04 Precise), handling source packages with quilt patches has become much easier."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:21
+# 1434e52e8905421fb549733f8ccba755
+msgid "There are two main tasks where you'll have to be aware of quilt patches, when developing your own patch to the upstream code, and when merging new versions of the package from Debian where either the Debian or Ubuntu (or both) have quilt patches in the source branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:26
+# b58a5bc7584f477d92f82add21cbecd0
+msgid "Here are some guidelines for working with quilt patches in UDD in these two scenarios.  Some of these techniques are works-in-progress, so you should adapt them to your own workflow, and keep watching for improvements from the Bazaar teams."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:33
+# 4fd2951efe3b48d9aa92e5c97a5046a5
+msgid "Patches are applied in source branches"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:35
+# 689b0681cd864bc6a2202b83b3ad3bc6
+msgid "One important thing to keep in mind: all source branches reflect the tree after a ``quilt push -a``.  In other words, when you branch a source branch from Launchpad, you get the tree with all patches applied, ready for you to jump right into hacking.  You do not need to ``quilt push -a`` manually, and in fact, you'll get a tree with lots of distracting modifications if you push or pop all the changes.  Or to put it another way, once you have a branch, jump right in!"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:45
+# edbb545a25ad4c11971b170125037114
+msgid "Merging from Debian with quilt patches"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:47
+# e9715e7c665747098f284eecfde3024d
+msgid "With newer versions of Bazaar as mentioned above, merging new Debian versions to Ubuntu versions should be quite easy now, even when one or both packages have quilt patches.  Just use ``bzr merge`` as you normally would.  Under the hood, Bazaar will first unapply all the patches, then do the merge, then if there are no conflicts, it will re-apply the patches leaving you again with a source branch in the ``quilt push -a`` state."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:54
+# eaa05e8c71a745ae850e574631031a92
+msgid "For example, if we want to merge the Debian version of the ``aptitude`` package with the Ubuntu version, we would do something like this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:64
+# 916812819c4341148647ea8c57bb0b2b
+msgid "If there are merge conflicts, the quilt patches will remain unapplied so that you can resolve the conflicts more easily.  You would use a combination of bzr and quilt commands to resolve the conflicts, until all the quilt patches are applied again.  Then you're ready to commit, push, and build as you normally would."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:72
+# f2b77350a5764ee4a465dc7f4e5861e5
+msgid "Develop your patch"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:74
+# 82bb00d948bd47f8866ee7c4f83627ab
+msgid "There is a strong preference to fixing packages using a patch system like quilt, rather than modifying the source code directly.  This is because with a patch system, it's easier to communicate those changes to Debian or upstream (where UDD isn't used), and to remove patches when upstream fixes the bug the patch addresses (possibly in a completely different way)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:80
+# 778a274b4f0a4c4594aa0b6d8f2b8ff7
+msgid "Let's say there's a bug in the ``dbus`` package that you want to fix.  You start the way you normally would with any package in UDD::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:89
+# 725d26b712d54930bd3fece4e1205c82
+msgid "Maybe the bug is pretty simple; there's a typo in the ``README`` file.  Just fix the typo in your favorite editor, then do a ``bzr stat`` to prove that the file has been edited::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:97
+# 2c0cd48d546e4ff880a11dbeb672b4ca
+msgid "Now, in order to get this fix into a quilt patch, we need to generate a diff, but we need the resulting patch to have a format that is consumable by quilt. The way to do that is to use the ``--prefix`` (or ``-p``) option to ``bzr diff``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:104
+# 6c6e406feab94466a83cd9083f63699c
+msgid "What this actually does is to produce a *level 1* diff, which is required by the quilt command we're going to use below.  Normally, ``bzr diff`` produces *level 0* diffs which are more easily read by humans, but this won't work with quilt (despite the implication in the quilt documentation)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:109
+# e01f1a39c4314baebed9a1b1e2a9c332
+msgid "The above command generates the patch and stores it in a file one level up from the working tree.  Note that here we're using the ``a`` and ``b`` directory prefixes for the diff, but the actual names don't really matter."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:113
+# 30363be3957a463eb045cefb1229290e
+msgid "Now all you need to do is to import the patch into your quilt patches.  If you named the file above with the same name you want into your quilt stack, then just do this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:120
+# 6f611850558d485f954a1b60ce5c5730
+msgid "You need the last line to inform Bazaar about the new quilt patch file.  You can see that the quilt patch's name is the same as the file name you generated above.  Of course, you can change this by using the ``-P`` option to ``quilt import``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:125
+# dc69c1cf032e4b1a8294928554dac138
+msgid "One important thing to notice is that if you do the commands ``bzr stat`` and a ``quilt applied`` , you'll see that the ``README`` file is still modified, but the ``bug-12345.patch`` is not yet applied.  If you try to apply the newly imported quilt patch (with ``quilt push``), it will fail because you're applying a patch on top of the already patched file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:131
+# eeec975299cf457d8eddae1b294020a7
+msgid "One way around this is to revert the change to ``README`` before doing the ``quilt push``.  However, if you think you may want to continue to develop the patch, and thus do not want to throw away your in-tree changes, use ``bzr shelve`` to save the change in the working tree to the side, then do ``quilt push``.  Either way, once you've pushed your top quilt patch, you can just edit the tree in place, and do ``quilt refresh`` commands to update the top quilt patch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:141
+# f31c5d24034845779d0438f7ce916170
+msgid "Gotchas"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:143
+# 3917fdae40bc40c5b56b50b902677d15
+msgid "One thing to keep in mind is that quilt uses a hidden ``.pc`` directory to record its status.  This directory is under version control in all source branches.  *Watch out* for changes to the ``.pc`` directory that are unrelated (or more accurately, uninteresting) to your patch.  This can happen because the UDD source branch importer `currently includes any existing .pc directory`_ in the imported branch.  This can cause conflicts, or other unwanted or unknown changes because you've essentially got two conflicting version control systems competing for the same thing (i.e. bzr and quilt3). For now, the best recommendation is to revert any changes to the ``.pc`` directory in your branch."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:156
+# d65a7f82fcd94ab68c6c627364d2aab3
+msgid "edit-patch"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:158
+# b0d8c677b4a54f5ca77d75fb30b8c294
+msgid "``edit-patch`` is a nice little wrapper script that comes as part of the ``ubuntu-dev-tools`` package.  It pretty much hides the nasty details of dealing with the patch system specifically.  For example, while the above works well if your package is using quilt already, you'll have to adjust the workflow, perhaps significantly, to work with `a different patch system`_.  In theory ``edit-patch`` should solve this, but there are currently two blockers."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:165
+# a6b9af6d3af64db99d2b68190dfbdfd3
+msgid "By default, ``bzr diff`` produces a ``-p0`` patch, but ``edit-patch`` defers to the underlying patch system's default.  For quilt, this is ``-p1``.  ``quilt import`` takes a ``-p`` argument to specify the prefix level, but this isn't yet exposed in ``edit-patch``.  If you use the ``--prefix`` argument to the ``bzr diff`` command as shown above, you should be okay."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-patchsys.rst:171
+# ce0e11f073b24f4185191bdbc191518a
+msgid "By default, ``edit-patch`` requires a path to an existing patch file, but it's more convenient to pipe the output of ``bzr diff`` to the stdin of ``edit-patch``, as shown above.  The alternative would be to save the diff in a temporary file, and then point ``edit-patch`` to this temporary file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:3
+# 7b1fc44173cb4391a096f4007ec9c56e
+msgid "Seeking Review and Sponsorship"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:5
+# d95d3d492bda47d4b503e101616df3ad
+msgid "One of the biggest advantages to using the UDD workflow is to improve quality by seeking review of changes by your peers.  This is true whether or not you have upload rights yourself.  Of course, if you don't have upload rights, you will need to seek sponsorship."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:10
+# 06bab422caf142839275125cbb83b8b2
+msgid "Once you are happy with your fix, and have a branch ready to go, the following steps can be used to publish your branch on Launchpad, link it to the bug issue, and create a *merge proposal* for others to review, and sponsors to upload."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:19
+# 3d62b9b1f8c34d3e9365e8e5c66e01cf
+msgid "Pushing to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:21
+# 1c70e306b96d4e2eb85f83a2a0b50255
+msgid "We previously showed you how to :ref:`associate your branch to the bug <link-via-changelog>` using ``dch`` and ``bzr commit``.  However, the branch and bug don't actually get linked until you push the branch to Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:25
+# 5c03b03b3018459a87e8d0255fda8159
+msgid "It is not critical to have a link to a bug for every change you make, but if you are fixing reported bugs then linking to them will be useful."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:28
+# d792e1921e3b43a0939226c7dab56f0a
+msgid "The general form of the URL you should push your branch to is::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:32
+# 5ff727debaf543b4827ed685006c64f3
+msgid "For example, to push your fix for bug 12345 in the Tomboy package for Natty, you'd use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:37
+# 5e4aec261f9c445fbacac4b444ab14d4
+msgid "The last component of the path is arbitrary; it's up to you to pick something meaningful."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:40
+# c7881ddc989f47c08a05fc8bdb33ec63
+msgid "However, this usually isn't enough to get Ubuntu developers to review and sponsor your change.  You should next submit a *merge proposal*."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:43
+# 4acecb6b0590401c9c3c3b34f7d9c6c4
+msgid "To do this open the bug page in a browser, e.g.::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:47
+# a58c58ac96f24e5b974fa5e1fd604700
+msgid "If that fails, then you can use::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:51
+# 432738e021a442d4993be0b661247073
+msgid "where most of the URL matches what you used for `bzr push`.  On this page, you'll see a link that says *Propose for merging into another branch*.  Type in an explanation of your change in the *Initial Comment* box.  Lastly, click *Propose Merge* to complete the process."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:56
+# 44bc83875c54474b88a148c193bf2145
+msgid "Merge proposals to package source branches will automatically subscribe the `~ubuntu-branches` team, which should be enough to reach an Ubuntu developer who can review and sponsor your package change."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:62
+# 0fca62fbb96b40f8b6a2f6d71b4e931b
+msgid "Generating a debdiff"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:64
+# 497f074532ea41a0ad2f0f737458c0f6
+msgid "As noted above, some sponsors still prefer reviewing a *debdiff* attached to bug reports instead of a merge proposal.  If you're requested to include a debdiff, you can generate one like this (from inside your `bug-12345` branch)::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:71
+# 0afe1b0f347d4262b8a653e63db9ea5e
+msgid "Another way is to is to open the merge proposal and download the diff."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:73
+# 05d3f3141ec3469ab72b15c0de583f17
+msgid "You should ensure that diff has the changes you expect, no more and no less. Name the diff appropriately, e.g. ``foobar-12345.debdiff`` and attach it to the bug report."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:79
+# 7dd6fe9d8c3b444f8860975c4a8b4f38
+msgid "Dealing with feedback from sponsors"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:81
+# 9e3b1d91bed845d2a6062e3f570b7409
+msgid "If a sponsor reviews your branch and asks you to change something, you can do this fairly easily.  Simply go to the branch that you were working in before, make the changes requested, and then commit::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:87
+# ad089e0df80b465eb7f1e40716314363
+msgid "Now when you push your branch to Launchpad, Bazaar will remembered where you pushed to, and will update the branch on Launchpad with your latest commits. All you need to do is::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:93
+# 77f8fca80f29434fbd5168392851dcc7
+msgid "You can then reply to the merge proposal review email explaining what you changed, and asking for re-review, or you can reply on the merge proposal page in Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-sponsorship.rst:97
+# 52c8fccf546c44c282c96dfa76047b7e
+msgid "Note that if you are sponsored via a debdiff attached to a bug report you need to manually update by generating a new diff and attaching that to the bug report."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:3
+# d617008018d04504ba3c700dbfd8a071
+msgid "Uploading a package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:5
+# 342b747163f4456a94be40e1565fab2d
+msgid "Once your merge proposal is reviewed and approved, you will want to upload your package, either to the archive (if you have permission) or to your `Personal Package Archive`_ (PPA).  You might also want to do an upload if you are sponsoring someone else's changes."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:12
+# b0cbfab07b0d4e37a98ac5b47602ba94
+msgid "Uploading a change made by you"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:14
+# ac079639095a4f71ae085f9ab67edee7
+msgid "When you have a branch with a change that you would like to upload you need to get that change back on to the main source branch, build a source package, and then upload it."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:18
+# 4eab51f33be241479a6671845543c543
+msgid "First, you need to check that you have the latest version of the package in your checkout of the development package trunk::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:24
+# 1e3dc7dfc78d4b1583d03def5dbc4ada
+msgid "This pulls in any changes that may have been committed while you were working on your fix.  From here, you have several options.  If the changes on the trunk are large and you feel should be tested along with your change you can merge them into your bug fix branch and test there.  If not, then you can carry on merging your bug fix branch into the development trunk branch.  As of bzr 2.5 and bzr-builddeb 2.8.1, this works with just the standard ``merge`` command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:34
+# 5c53b237d933489fb5dff7a6cb8065dd
+msgid "For older versions of bzr, you can use the ``merge-package`` command instead::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:38
+# cd5c586ed03f4cfd80f044d00f56de68
+msgid "This will merge the two trees, possibly producing conflicts, which you'll need to resolve manually."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:41
+# 8b79d8ef643e4180a1f3a44ae9d0a774
+msgid "Next you should make sure the ``debian/changelog`` is as you would like, with the correct distribution, version number, etc."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:44
+# 144b9deb49ad4e5f8ee0d1b34cd8a44d
+msgid "Once that is done you should review the change you are about to commit with ``bzr diff``.  This should show you the same changes as a debdiff would before you upload the source package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:48
+# 21d5018d7bf44760b14279b4eef579f5
+msgid "The next step is to build and test the modified source package as you normally would::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:53
+# 52f286ea39024b6f9e2589ae45062601
+msgid "When you're finally happy with your branch, make sure you've committed all your changes, then tag the branch with the changelog's version number.  The ``bzr tag`` command will do this for you automatically when given no arguments::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:60
+# 99b97002ffe34973979d24ac1668f787
+msgid "This tag will tell the package importer that what is in the Bazaar branch is the same as in the archive."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:63
+# ebeb745e0c11434c8dcb15cc023ddeb7
+msgid "Now you can push the changes back to Launchpad::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:67
+# 2eb1de1779694bf881e03fd5a67d2af0
+msgid "(Change the destination if you are uploading an SRU or similar.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:69
+# 8ebd6bfad0e34d93890640c2bf1b787c
+msgid "You need one last step to get your changes uploaded into Ubuntu or your PPA; you need to ``dput`` the source package to the appropriate location.  For example, if you want to upload your changes to your PPA, you'd do::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:75
+# 5a2f077286fb4c7c8f35d5f181dfe020
+msgid "or, if you have permission to upload to the primary archive::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:79
+# 9b550ebec58249fbb0fe679464b92453
+msgid "You are now free to delete your feature branch, as it is merged, and can be re-downloaded from Launchpad if needed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:84
+# 7df92bf7f57846d9af9f8f9d356bec2c
+msgid "Sponsoring a change"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:86
+# f9eb51784cf6440ab1e92567c03feddc
+msgid "Sponsoring someone else's change is just like the above procedure, but instead of merging from a branch you created, you merge from the branch in the merge proposal::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:92
+# 0419a82213944aa5b48804bb6534d32d
+msgid "If there are lots of merge conflicts you would probably want to ask the contributor to fix them up.  See the next section to learn how to cancel a pending merge."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:96
+# 0e05452bf9e74469a5de534b92482d86
+msgid "But if the changes look good, commit and then follow the rest of the uploading process::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:103
+# 4397bec4fb934bc89cbcb5935485c0eb
+msgid "Canceling an upload"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:105
+# ccfa3957ac2b47b48e4604768f4af77b
+msgid "At any time before you `dput` the source package you can decide to cancel an upload and revert the changes::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:110
+# 8383aa45362241cbbffaefa37a7ef327
+msgid "You can do this if you notice something needs more work, or if you would like to ask the contributor to fix up conflicts when sponsoring something."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:115
+# 4b45467e48e041d5999db11c24113b1e
+msgid "Sponsoring something and making your own changes"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:117
+# fe4a60bef7e44faeaa7348763b2e8abb
+msgid "If you are going to sponsor someone's work, but you would like to roll it up with some changes of your own then you can merge their work in to a separate branch first."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:121
+# 79453712dc2d473eb3c770c9d46d305b
+msgid "If you already have a branch where you are working on the package and you would like to include their changes, then simply run the ``bzr merge`` from that branch, instead of the checkout of the development package.  You can then make the changes and commit, and then carry on with your changes to the package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:127
+# 2ad47a1cf0a040a7a39e87a520e87a30
+msgid "If you don't have an existing branch, but you know you would like to make changes based on what the contributor provides then you should start by grabbing their branch::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-uploading.rst:133
+# a36da929444f4aa79853824f5fad7825
+msgid "then work in this new branch, and then merge it in to the main one and upload as if it was your own work.  The contributor will still be mentioned in the changelog, and Bazaar will correctly attribute the changes they made to them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:3
+# 668df6a55d7d4262959051aff523f18a
+msgid "Working on a Package"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:5
+# 325df7ee56fc4514946bee8d8d9833a3
+msgid "Once you have the source package branch in a shared repository, you'll want to create additional branches for the fixes or other work you plan to do.  You'll want to base your branch off the package source branch for the distro release that you plan to upload to.  Usually this is the current development release, but it may be older releases if you're backporting to an SRU for example."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:13
+# 3bbdede17cae472d9f3cb41c285ec0a0
+msgid "Branching for a change"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:15
+# 9932a9319bf948698e1efbac7555a3b6
+msgid "The first thing to do is to make sure your source package branch is up-to-date.  It will be if you just checked it out, otherwise do this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:21
+# 6e748312dd324667b18e6eb5cb0503ec
+msgid "Any updates to the package that have uploaded since your checkout will now be pulled in.  You do not want to make changes to this branch.  Instead, create a branch that will contain just the changes you're going to make.  Let's say you want to fix bug 12345 for the Tomboy project.  When you're in the shared repository you previously created for Tomboy, you can create your bug fix branch like this::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:31
+# fcc7556739024f40b1b51f39aa13ca55
+msgid "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)::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:39
+# 5faa703321cd4d9cb342e35caaab81ac
+msgid "This will drop you in an editor to add an entry to the `debian/changelog` file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:44
+# 6dc1cbcab4874dc589194be12f2d232e
+msgid "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 like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:57
+# da1d850b11fe4bb485d5be846264f366
+msgid "Commit with the normal::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:61
+# 4536113fa1c745dd9e502d526185f8ed
+msgid "A hook in bzr-builddeb will use the debian/changelog text as the commit message and set the tag to mark bug #12345 as fixed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:64
+# 9f3672cba68a4714ad6a5deacb93dc6e
+msgid "This only works with bzr-builddeb 2.7.5 and bzr 2.4, for older versions use `debcommit`."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:71
+# 86ee6fff8e524ab1bac18e701df02f1b
+msgid "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."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:74
+# 98afbf48360941e5b164fa1d32a48659
+msgid "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::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:79
+# e6bd918c14214ff4926e67edf70e2ecf
+msgid "(`bd` is an alias for `builddeb`.)  You can leave the package unsigned by appending `-- -uc -us` to the command."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:82
+# c4d3a439bc0443f5b843f22078807d77
+msgid "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.::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:87
+# eff4ddb86f804ce2a5686727949160e0
+msgid "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 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."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/udd-working.rst:94
+# d006ba6b5e3946e8a3778fa2ec263b31
+msgid "Once you've got the source package, you can build it as normal with ``pbuilder-dist`` (or ``pbuilder`` or `sbuild`_)."
+msgstr ""
+

=== added file 'po/ubuntu-packaging-guide.pot'
--- po/ubuntu-packaging-guide.pot	1970-01-01 00:00:00 +0000
+++ po/ubuntu-packaging-guide.pot	2012-03-20 20:48:20 +0000
@@ -0,0 +1,3182 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) 2010-2012, Ubuntu Developers
+# This file is distributed under the same license as the ubuntu-packaging-guide package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: ubuntu-packaging-guide 0.1\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2012-02-29 17:52\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <[e-mail]>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../ubuntu-packaging-guide/chroots.rst:3
+# d6c7ecbd606c4b9282b23708db85f9b5
+msgid "Using Chroots"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:5
+# c2a9180a73924eb0b652907be2585c5d
+msgid "If you are running one version of Ubuntu but working on packages for another versions you can create the environment of the other version with a ``chroot``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:9
+# 6634399d63e843f4b72b0f770fafd076
+msgid "A ``chroot`` allows you to have a full filesystem from another distribution which you can work in quite normally.  It avoids the overhead of running a full virtual machine."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:14
+# feb922fa269d4d50913b3692dea2800f
+msgid "Creating a Chroot"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:16
+# 84f92237b55541a2b463749f2521ca05
+msgid "Use the command ``debootstrap`` to create a new chroot::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:20
+# 9208c7dbf8d84b5eb0fd24fab308ff5c
+msgid "This will create a directory ``oneiric`` and install a minimal oneiric system into it."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:23
+# 2f24711099184a0ba8f80c20edc1adc2
+msgid "If your version of ``debootstrap`` does not know about oneiric you can try upgrading to the version in ``backports``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:26
+# 0575a501ac4448359c69b30b55550435
+msgid "You can then work inside the chroot::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:30
+# 6b1f042f6de1476db33347866860441c
+msgid "Where you can install or remove any package you wish without affecting your main system."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:33
+# 9536d8f2c01e43648648496a446eeb6e
+msgid "You might want to copy your GPG/ssh keys and Bazaar configuration into the chroot so you can access and sign packages directly."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:36
+# e6d516f40fee4cc2972525ec9b13615e
+msgid "$ sudo mkdir oneiric/home/<username> $ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar oneiric/home/<username>"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:39
+# ed82e18debb24933ad3b49492b196442
+msgid "To stop apt and other programs complaining about missing locales you can install your relevant language pack::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:44
+# 7d9703bd6d9148daa5980a104d8d13ef
+msgid "If you want to run X programs you will need to bind the /tmp directory into the chroot, from outside the chroot run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:50
+# 3c056ca4d3b54c53bca74c2cc2025835
+msgid "Some programs may need you to bind /dev or /proc."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:52
+# 7164d56709d64a9e83edc09bf710fce7
+msgid "For more information on chroots see our `Debootstrap Chroot wiki page`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:55
+# 26aacfbeebe4473f9e1244c3c974b6ff
+msgid "Alternatives"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:57
+# f085504840904fcb995131456d3036d7
+msgid "SBuild is a system similar to PBuilder for creating an environment to run test package builds in.  It closer matches that used by Launchpad for building packages but takes some more setup compared to PBuilder.  See `the Security Team Build Environment wiki page`_ for a full explanation."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:59
+# 9fa7e581df034a33a4503a7a41b37017
+msgid "Full virtual machines can be useful for packaging and testing programmes.  TestDrive is a program to automate syncing and running daily ISO images, see `the TestDrive wiki page`_ for more information."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:63
+# 112cec755e0d4ac5a0e1e20df59807f8
+msgid "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."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/chroots.rst:67
+# 1367b95423434ae9b8d2687c8c100771
+msgid "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 version and package on those.  This is useful when you want to compile many packages at the same time or to overcome bandwidth restraints."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:3
+# 607298b09c134c8497b9dd820a18456f
+msgid "Communication in Ubuntu Development"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:5
+# 02e7427cdd1a4e48b9f0dfa256715944
+msgid "In a project where thousands of lines of code are changed, lots of decisions are made and hundreds of people interact every day, it is important to communicate effectively."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:10
+# 8dff4e5170734f698bbb51c6807b7dcf
+msgid "Mailing lists"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:12
+# 7bdd3f8f13b34307a06a05656c94760b
+msgid "Mailing lists are a very important tool if you want to communicate ideas to a broader team and make sure that you reach everybody, even across timezones."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:16
+# ec54a70a969342e58399443508c91e33
+msgid "In terms of development, these are the most important ones:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:18
+# c583284d21a5478e973448d96344c720
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (announce-only, the most important development announcements go here)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:20
+# 187731122f5045a09748d70e00456b4c
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (general Ubuntu development discussion)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:22
+# 38f45dd72cfd4f64bc0e64af440c45c2
+msgid "https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (MOTU Team discussion, get help with packaging)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:27
+# bcf8bf4cfd7d44e79964fc504e3dcbcf
+msgid "IRC Channels"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:29
+# 1640a1e73721469dbb00fb44535008f2
+msgid "For real-time discussions, please connect to irc.freenode.net and join one or any of these channels:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:32
+# 54b7cb96eed649698da71070bdcec51b
+msgid "#ubuntu-devel (for general development discussion)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/communication.rst:33
+# 9d87672ae32043ec8c0a9f2bca0b7dd4
+msgid "#ubuntu-motu (for MOTU team discussion and generally getting help)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:2
+# 89800d29a2d548768207920d6fb6d7b3
+msgid "Basic Overview of the ``debian/`` Directory"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:4
+# 7d1e060c05644770b508535c347508a1
+msgid "This article will briefly explain the different files important to the packaging of Ubuntu packages which are contained in the ``debian/`` directory. The most important of them are ``changelog``, ``control``, ``copyright``, and ``rules``. These are required for all packages. A number of additional files in the ``debian/`` may be used in order to customize and configure the behavior of the package. Some of these files are discussed in this article, but this is not meant to be a complete list."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:13
+# 3021836f0c23449690b60757ce61172a
+msgid "The changelog"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:15
+# 31bd62153b0d408bb34738128c941836
+msgid "This file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time. If you have a GPG key (see: :doc:`Getting set up<./getting-set-up/>`), make sure to use the same name and email address in ``changelog`` as you have in your key. The following is a template ``changelog``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:31
+# 615d3cedb82c4d399c625d3986b6c75e
+msgid "The format (especially of the date) is important. The date should be in :rfc:`5322` format, which can be obtained by using the command ``date -R``. For convenience, the command ``dch`` may be used to edit changelog. It will update the date automatically."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:36
+# 3d1b93961c0a46a4b77382e11822dd08
+msgid "Minor bullet points are indicated by a dash \"-\", while major points use an asterisk \"*\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:39
+# 3c8e29b2b199417083f23153de4c94c4
+msgid "If you are packaging from scratch, ``dch --create`` (``dch`` is in the ``devscripts`` package) will create a standard ``debian/changelog`` for you."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:43
+# 0f6505553bb0491d9f0247c37f87cf9a
+msgid "Here is a sample ``changelog`` file for hello::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:52
+# 3f1fd2f3b89a4e36aff77a170ba8c656
+msgid "Notice that the version has a ``-0ubuntu1`` appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:56
+# 8500e33e8dae496d9bab351d1f1f0a0d
+msgid "Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ``ubuntuX`` (where ``X`` is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello ``2.6-1`` package was changed by Ubuntu, the version string would be ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:64
+# 8a1028b5e61244339a21d8fdf991cd73
+msgid "For further information, see the `changelog section (Section 4.4) <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:70
+# 552ad1faf3814524bd838abbb1c6dfde
+msgid "The control file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:72
+# 0a7a9cd926a5482090b334ae4eb5fa76
+msgid "The ``control`` file contains the information that the package manager (such as ``apt-get``, ``synaptic``, and ``adept``) uses, build-time dependencies, maintainer information, and much more."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:76
+# 2c2caa9a9fef495dad29ffa07ab52d4a
+msgid "For the Ubuntu ``hello`` package, the ``control`` file looks something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:99
+# bd3ddeb9c3fd445ba6df546d419ec391
+msgid "The first paragraph describes the source package including the list of packages required to build the package from source in the ``Build-Depends`` field. It also contains some meta-information such as the maintainer's name, the version of Debian Policy that the package complies with, the location of the packaging version control repository, and the upstream home page."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:106
+# 93b0eec4843d4f819ba16118070fbbdf
+msgid "Note that in Ubuntu, we set the ``Maintainer`` field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team). Packages in Ubuntu should generally have the ``Maintainer`` field set to ``Ubuntu Developers <[e-mail]>``. If the Maintainer field is modified, the old value should be saved in the ``XSBC-Original-Maintainer`` field. This can be done automatically with the  ``update-maintainer`` script available in the ``ubuntu-dev-tools`` package. For further information, see the `Debian Maintainer Field spec <https://wiki.ubuntu.com/DebianMaintainerField>`_ on the Ubuntu wiki."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:118
+# 00ca42e43f314557af47bf373ae50fe6
+msgid "Each additional paragraph describes a binary package to be built."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:120
+# a48f51f0912a4312a904ab5f40ced13d
+msgid "For further information, see the `control file section (Chapter 5) <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:126
+# 870ce0ac216c4fd8a10aa642d5a8ee12
+msgid "The copyright file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:128
+# a8f880bcb0174968b217b52dfc303a34
+msgid "This file gives the copyright information for both the upstream source and the packaging. Ubuntu and `Debian Policy (Section 12.5) <http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>`_ require that each package installs a verbatim copy of its copyright and license information to ``/usr/share/doc/$(package_name)/copyright``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:134
+# 73c9109a50ce4e2c8d6ce22c64df57dd
+msgid "Generally, copyright information is found in the ``COPYING`` file in the program's source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. An example template would be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:176
+# 7a2e84d5a9304d2fb327fc2d39a75a45
+msgid "This example follows the `Machine-readable debian/copyright <http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>`_ format. You are encouraged to use this format as well."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:182
+# 7c0fe27bc8fa4cb192be460e57dde489
+msgid "The rules file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:184
+# 7c9e2edb563c4fe894feeae0b17007c7
+msgid "The last file we need to look at is ``rules``. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the ``.deb`` file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:192
+# 299ff74602f94f758774713d29895440
+msgid "Here is a simplified version of the rules file created by ``dh_make`` (which can be found in the ``dh-make`` package)::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:204
+# 94a7b044a9824b13b733ffe6b5ee57b5
+msgid "Let us go through this file in some detail. What this does is pass every build target that ``debian/rules`` is called with as an argument to ``/usr/bin/dh``, which itself will call all the necessary ``dh_*`` commands."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:208
+# de59039f8bd245d7971edf916d93a839
+msgid "``dh`` runs a sequence of debhelper commands. The supported sequences correspond to the targets of a ``debian/rules`` file: \"build\", \"clean\", \"install\", \"binary-arch\", \"binary-indep\", and \"binary\". In order to see what commands are run in each target, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:217
+# 7d39368e13994bedac97c6e43018bbb2
+msgid "Commands in the binary-indep sequence are passed the \"-i\" option to ensure they only work on binary independent packages, and commands in the binary-arch sequences are passed the \"-a\" option to ensure they only work on architecture dependent packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:222
+# 9aeaa267814c4f199174eb45833f25c2
+msgid "Each debhelper command will record when it's successfully run in ``debian/package.debhelper.log``. (Which dh_clean deletes.) So dh can tell which commands have already been run, for which packages, and skip running those commands again."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:227
+# efa044d38ff14eebb1b18fab6a0d594d
+msgid "Each time ``dh`` is run, it examines the log, and finds the last logged command that is in the specified sequence. It then continues with the next command in the sequence. The ``--until``, ``--before``, ``--after``, and ``--remaining`` options can override this behavior."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:232
+# d01ecd38632646f4b2bbaf1c8a08477d
+msgid "If ``debian/rules`` contains a target with a name like ``override_dh_command``, then when it gets to that command in the sequence, ``dh`` will run that target from the rules file, rather than running the actual command. The override target can then run the command with additional options, or run entirely different commands instead. (Note that to use this feature, you should Build-Depend on debhelper 7.0.50 or above.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:241
+# 3f4e235a68754876866310c506863f75
+msgid "Have a look at ``/usr/share/doc/debhelper/examples/`` and ``man dh`` for more examples. Also see `the rules section (Section 4.9) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:247
+# 909152843c7c41ffa14664f13cb0e23f
+msgid "Additional Files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:250
+# f6ef0e8b2e5149f59850c2425711b97f
+msgid "The install file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:252
+# 526e3303d4d44e27a3ceefc4764a54c9
+msgid "The ``install`` file is used by ``dh_install`` to install files into the binary package. It has two standard use cases:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:255
+# 8f1de6bb1994494b807ec69b3af9e2ff
+msgid "To install files into your package that are not handled by the upstream build system."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:256
+# ecb71f5a256c4c0ab18dd78194054e68
+msgid "Splitting a single large source package into multiple binary packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:258
+# b540bec3330242b48b8b6c6f34cfacf6
+msgid "In the first case, the ``install`` file should have one line per file installed, specifying both the the file and the installation directory. For example, the following ``install`` file would install the script ``foo`` in the source package's root directory to ``usr/bin`` and a desktop file in the ``debian`` directory to ``usr/share/applications``::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:269
+# cdd19fc100104c8ea9f0588252dfa8cb
+msgid "When a source package is producing multiple binary packages ``dh`` will install the files into ``debian/tmp`` rather than directly into ``debian/<package>``. Files installed into ``debian/tmp`` can then be moved into separate binary packages using multiple ``$package_name.install`` files. This is often done to split large amounts of architecture independent data out of architecture dependent packages and into ``Architecture: all`` packages. In this case, only the name of the files (or directories) to be installed are needed without the installation directory. For example, ``foo.install`` containing only the architecture dependent files might look like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:282
+# 490646dff688435088bd93ff30de6a8a
+msgid "While ``foo-common.install`` containing only the architecture independent file might look like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:290
+# ad5ae2bd9270403fb9916024351646c9
+msgid "This would create two binary packages, ``foo`` and ``foo-common``. Both would require their own paragraph in ``debian/control``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:293
+# ed10a77119a6408b8a5f7bfebc53500e
+msgid "See ``man dh_install`` and the `install file section (Section 5.11) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install>`_  of the Debian New Maintainers' Guide for additional details."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:298
+# 2bce7b3f508c457eb566c77de679acd7
+msgid "The watch file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:300
+# d22412241e7349bfa19c0ca46d59fa93
+msgid "The ``debian/watch`` file allows us to check automatically for new upstream versions using the tool ``uscan`` found in the ``devscripts`` package. The first line of the watch file must be the format version (3, at the time of this writing), while the following lines contain any URLs to parse. For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:309
+# 3fd98ffeb19c4a2290a8fec31eed399c
+msgid "Running ``uscan`` in the root source directory will now compare the upstream version number in ``debian/changelog`` with the latest available upstream version. If a new upstream version is found, it will be automatically downloaded. For example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:322
+# a4a1f7731ea6433ca39eecbd57af3120
+msgid "For further information, see ``man uscan`` and the `watch file section (Section 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ of the Debian Policy Manual."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:326
+# 703b5d062b5c41e5a60cf8801b69b893
+msgid "For a list of packages where the ``watch`` file reports they are not in sync with upstream see `Ubuntu External Health Status <http://qa.ubuntuwire.org/uehs/no_updated.html>`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:331
+# faa634aa8992448d86ad70c8669ceee1
+msgid "The source/format file"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:333
+# a348a6a009424e0fa49a866e129573a2
+msgid "This file indicates the format of the source package. It should contain a single line indicating the desired format:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:336
+# 3d75a73a1fcd4342ab1fe865edf49644
+msgid "``3.0 (native)`` for Debian native packages (no upstream version)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:338
+# fd11f4ebad4d45bcbac715f3d8d4cc92
+msgid "``3.0 (quilt)`` for packages with a separate upstream tarball"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:340
+# 1293ceef3ce04d30b640542aec2b476c
+msgid "``1.0`` for packages wishing to explicitly declare the default format"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:342
+# 4e5d823b97ab4704aba10fb129ed0106
+msgid "Currently, the package source format will default to 1.0 if this file does not exist. You can make this explicit in the source/format file. If you choose not to use this file to define the source format, Lintian will warn about the missing file. This warning is informational only and may be safely ignored."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:347
+# d7047d3e7c22489baedfec02eea21f25
+msgid "You are encouraged to use the newer 3.0 source format. It provides a number of new features:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:350
+# bc4e7971f98848ae9f1fb3fd8ee97ace
+msgid "Support for additional compression formats: bzip2, lzma and xz"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:352
+# ddca8f575fac40e09adebd6d128ff676
+msgid "Support for multiple upstream tarballs"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:354
+# aded08ffbdb7449d88dd6010fd97766f
+msgid "Not necessary to repack the upstream tarball to strip the debian directory"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:356
+# b0f4d5d0c68e47de9ed8836f20a0e8be
+msgid "Debian-specific changes are no longer stored in a single .diff.gz but in multiple patches compatible with quilt under ``debian/patches/``"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:358
+# 39b0c8ccca7e48b7af1af09d580e9f58
+msgid "http://wiki.debian.org/Projects/DebSrc3.0 summarizes additional information concerning the switch to the 3.0 source package formats."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:361
+# 9d2f31ea080c47109ce2cdae3e87f14b
+msgid "See ``man dpkg-source`` and the `source/format section (Section 5.21) <http://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcef>`_  of the Debian New Maintainers' Guide for additional details."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:366
+# 62fbf7d7bdcb49e782e64f2623b6f273
+msgid "Additional Resources"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/debian-dir-overview.rst:368
+# 039aa564015a48bda02c00b97d1ae2f3
+msgid "In addition to the links to the Debian Policy Manual in each section above, the Debian New Maintainers' Guide has more detailed descriptions of each file. `Chapter 4, \"Required files under the debian directory\" <http://www.debian.org/doc/maint-guide/dreq.en.html>`_ further discusses the control, changelog, copyright and rules files. `Chapter 5, \"Other files under the debian directory\" <http://www.debian.org/doc/maint-guide/dother.en.html>`_ discusses additional files that may be used."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:3
+# 4be28eeaaecb4fffa9bcfb62c8828b58
+msgid "Fixing a bug in Ubuntu"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:6
+#: ../ubuntu-packaging-guide/security-and-stable-release-updates.rst:9
+# 5973d64df73b4f8593c75fcac478a00e
+# e0956744ffbc47c08a5bb87b139bb113
+msgid "Introduction"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:8
+# d4425948fa1e4b4fa3552113dc4dd00d
+msgid "If you followed the instructions to :doc:`get set up with Ubuntu Development<./getting-set-up>`, you should be all set and ready to go."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:11
+# 02b036432f59412c82aed419f79fdb8c
+msgid "..image:: |IMG|fixing-a-bug.png"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:13
+# 565e30b78a5c41b8990814dc8aaf9193
+msgid "As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:20
+# 65a1fad6a3d04bbf8fc8932a8dbf6061
+msgid "Finding the problem"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:22
+# e8e70d62917543ed8b9b8f081ba09518
+msgid "There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:26
+# 1c114b6ed4044179acbfa298d17e8687
+msgid "`Harvest <http://harvest.ubuntu.com/>`_ is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them 'bitesize'), and so on. Check it out and find your first bug to work on."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:35
+# b454c63458594749aa09f9e587ed24a7
+msgid "Figuring out what to fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:37
+# e80c8c6721fe41ddb9d3976bea810f18
+msgid "If you don't know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you'll need to work on."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:41
+# 4726f96b219c4bfeb111d18b723e771e
+msgid "Let's say you've found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running ``/usr/bin/tomboy`` on the command line.  To find the binary package containing this application, use this command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:48
+# dbf4f211a56f4f79b15bf42c6a835050
+msgid "This would print out::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:52
+# 682b18dbdfe142d2affc3e04e843783f
+msgid "Note that the part preceding the colon is the binary package name.  It's often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages.  To find the source package for a particular binary package, type::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:64
+# b7321dfe18ed434689e1617b5ad1b575
+msgid "Getting the code"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:66
+# a88040229e1343e3a881389f2388861f
+msgid "Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it.  In Ubuntu Distributed Development this is done by :ref:`*branching* the source package <branching>` branch corresponding to the source package.  Launchpad maintains source package branches for all the packages in Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:72
+# 92bb0cef4a5a4924afaff6a5bd97394f
+msgid "Once you've got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch.  When you are happy with your fix, you can :ref:`submit a *merge proposal* <merge-proposal>`, which asks other Ubuntu developers to review and approve your change.  If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit of your excellent fix - and you get a little bit of credit.  You're now on your way to becoming an Ubuntu developer!"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:81
+# 18ebcba0d9804cdcbd3d7b679124afba
+msgid "We'll describe specifics on how to branch the code, push your fix, and request a review in the following sections."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:86
+# e8950446f9d643f9a88454cb13406165
+msgid "Work on a fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:88
+# 0b597e2df21d4ffb9082682062b35f5b
+msgid "There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:93
+# 1cad1f33d073486abd5bbd7950da19e1
+msgid "Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:96
+# 9cd02b0b46194cb0a6e1c024c73d67bb
+msgid "Upstream (and Debian) bug tracker (open and closed bugs),"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:97
+# fe3658bb50d6453d839bae201ab3e0d3
+msgid "Upstream revision history (or newer release) might have fixed the problem,"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:98
+# dc982aac83c44804b15e226836d039fd
+msgid "bugs or package uploads of Debian or other distributions."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:103
+# 3d5234f7f891414eac096bc475484247
+msgid "You now want to create a patch which includes the fix.  The command ``edit-patch`` is a simple way to add a patch to a package. Run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:108
+# e09e4812312c4fdc854bd3814b092ebb
+msgid "This will copy the packaging to a temporary directory.  You can now edit files with a text editor or apply patches from upstream, for example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:113
+# 8e00895b4bf64119869e26ce978cb55b
+msgid "After editing the file type ``exit`` or press ``control-d`` to quit the temporary shell.  The new patch will have been added into ``debian/patches``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:118
+# a5e56006a7db42a2b5b976f351e1a93a
+msgid "Testing the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:120
+# 29f45bb94cae448f9ff6bd53897237ab
+msgid "To build a test package with your changes, run these commands::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:125
+# 6fd80448fb9b40668a73b68d9aa82ee9
+msgid "This will create a source package from the branch contents (``-us -uc`` will just omit the step to sign the source package) and ``pbuilder-dist`` will build the package from source for whatever ``release`` you choose."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:129
+# 7064dcf9f1ae4f49bacc8b5ebb79a4fb
+msgid "Once the build succeeds, install the package from ``~/pbuilder/<release>_result/`` (using ``sudo dpkg -i <package>_<version>.deb``).  Then test to see if the bug is fixed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:136
+# a498c34018d44bc083c421d3836bc292
+msgid "Documenting the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:138
+# 284aad9da256489bb9541ef9c9ed8050
+msgid "It is very important to document your change sufficiently so developers who look at the code in the future won't have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes ``debian/changelog``, where changes of each uploaded package are tracked."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:143
+# c560a925fc79452f85c60a462422febd
+msgid "The easiest way to update this is to run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:147
+# fc6305e6f22b4bbe8f7ae46d9d2d36fe
+msgid "This will add a boilerplate changelog entry for you and launch an editor where you can fill in the blanks. An example of this could be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:156
+# b4fcf5a54df94852b901b81d99177166
+msgid "``dch`` should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is 'low'). The last line always contains the name, email address and timestamp (in :rfc:`5322` format) of the change."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:162
+# 245b3f4735b2450db24ddca21be8e504
+msgid "With that out of the way, let's focus on the actual changelog entry itself: it is very important to document:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:165
+# 43f30ecd000741b2849656bfa9c6ae55
+msgid "where the change was done"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:166
+# 6aa10c8f84ff4278888e5edc11cfdf66
+msgid "what was changed"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:167
+# a48a34986f8248b891f819d4abcff85c
+msgid "where the discussion of the change happened"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:169
+# b5105651513148e58182645ef1350d2b
+msgid "In our (very sparse) example the last point is covered by ``(LP: #123456)`` which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the ``LP: #<number>`` notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:178
+# 7e3ca41954e44f68bcbe1755d6a53f74
+msgid "Committing the fix"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:180
+# 8931133984c348d5991fb0d11db638e0
+msgid "With the changelog entry written and saved, you can just run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:184
+# 694988e85f33437b9af1ab2c8a9192af
+msgid "and the change will be committed (locally) with your changelog entry as a commit message."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:187
+# c7c33ddc56cd406cb79afea806a24ab7
+msgid "To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:192
+# d43eb74f6725404a8e0c12ee36207d3d
+msgid "This could for example be::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:196
+# 9c95cd25baca4246bf40816093dc7f7a
+msgid "So if you just run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/fixing-a-bug.rst:201
+# 5aa8ae3e79484b43bf7f43d93010513b
+msgid "you should be all set. The push command should push it to Launchpad and the second command will open the Launchpad page of the remote branch in your browser. There find the \"(+) Propose for merging\" link, click it to get the change reviewed by somebody and included in Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:3
+# 83f85e65560046f4b62f45e17b49a17a
+msgid "Getting Set Up"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:5
+# a66b7a19ac434a5a909505514b2926ca
+msgid "There are a number of things you need to do to get started developing for Ubuntu. This article is designed to get your computer set up so that you can start working with packages, and upload your packages to Ubuntu's hosting platform, Launchpad. Here's what we'll cover:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:10
+# 086a9c5ecf2d449b82843d303d58a164
+msgid "Installing packaging-related software. This includes:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:12
+# 400b8ae2a4554bb484ea4554b8fdd56d
+msgid "Ubuntu-specific packaging utilities"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:13
+# e062bc0cc3ed4294b33616a98d4a5a4d
+msgid "Encryption software so your work can be verified as being done by you"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:14
+# 925d91caef104cb7afa6001f05680be9
+msgid "Additional encryption software so you can securely transfer files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:16
+# b0e396c2d5f4463c96d854f06c659d6a
+msgid "Creating and configuring your account on Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:17
+# 4d333df7195b41f6b125d660b2a1c300
+msgid "Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:22
+# 9c69c6eea045429a8a34b6fe96139751
+msgid "It is advisable to do packaging work using the current development version of Ubuntu. Doing so will allow you to test changes in the same environment where those changes will actually be applied and used."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:26
+# 7c484a283dd34e39a18323d9beac87f9
+msgid "Don't worry though, the `Ubuntu development release wiki page <https://wiki.ubuntu.com/UsingDevelopmentReleases>`_ shows a variety of ways to safely use the development release."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:32
+# b98ebc64ff574a5dbf0bdbd1df7a6c8f
+msgid "Install basic packaging software"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:34
+# 808a29c5f38f448eb25ca66e04792f0f
+msgid "There are a number of tools that will make your life as an Ubuntu developer much easier.  You will encounter these tools later in this guide.  To install most of the tools you will need run this command::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:41
+# fac16697cacf4355a80e8f5b88f324a0
+msgid "Note: Since Ubuntu 11.10 \"Oneiric Ocelot\" (or if you have Backports enabled on a currently supported release), the following command will install the above and other tools which are quite common in Ubuntu development::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:49
+# 49e40cea430146ec8c2692a2a6bcd425
+msgid "This command will install the following software:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:51
+# 4e959df03bee4ba6a973d4f2cbffec9d
+msgid "``gnupg`` -- `GNU Privacy Guard`_ contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:54
+# 1c457996b9ff49cfb8720509a4314a6d
+msgid "``pbuilder`` -- a tool to do a reproducible builds of a package in a clean and isolated environment."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:56
+# e9c0f3fd07be45c2928f88eb383771ed
+msgid "``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a collection of tools that make many packaging tasks easier."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:58
+# 29db292e4464422eb0e4e6222af33ef5
+msgid "``bzr-builddeb`` (and ``bzr``, a dependency) -- distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:62
+# 9f5925a4d2014953af7c6070b31a157c
+msgid "``apt-file`` provides an easy way to find the binary package that contains a given file."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:64
+# 2110c86d771140b7bc69c2958b28464d
+msgid "``apt-cache`` (part of the ``apt`` package) provides even more information about packages on Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:69
+# 0a14b46fec014f97bd7557e4d9258941
+msgid "Create your GPG key"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:71
+# 16d8e0261d5a48dfb0ff6aeede808b34
+msgid "GPG stands for `GNU Privacy Guard`_ and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:78
+# c25b4a7c3abd47c4adab9c0d4a8f88e4
+msgid "To generate a new GPG key, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:82
+# 854929b1b9b74e56a91d8cdac1b6ccbf
+msgid "GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say \"0\", which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. Then you will have to set a passphrase, choose a safe one (a passphrase is just a password which is allowed to include spaces)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:92
+# c9411759e55c44f7b4ff04ab876850e9
+msgid "Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine.  Move the cursor around, type some paragraphs of random text, load some web page."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:97
+# 671e66dd26de4cc19167919c4cacf056
+msgid "Once this is done, you will get a message similar to this one::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:104
+# fbcfbe47756f426092c3860dad3c1fec
+msgid "In this case ``43CDE61D`` is the *key ID*."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:106
+# 5bcf72402a81478a8210db244d7a62f9
+msgid "Next, you need to upload the public part of your key to a keyserver so the world can identify messages and files as yours. To do so, enter::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:111
+# 457a5844d06c44969821537e48cdf762
+msgid "This will send your key to one keyserver, but a network of keyservers will automatically sync the key between themselves. Once this syncing is complete, your signed public key will be ready to verify your contributions around the world."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:118
+# bbd6cfc0f36241b9afc8304a4955b10f
+msgid "Create your SSH key"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:120
+# cbe44e54369c43ccbaf972bb10995704
+msgid "SSH_ stands for *Secure Shell*, and it is a protocol that allows you to exchange data in a secure way over a network. It is common to use SSH to access and open a shell on another computer, and to use it to securely transfer files. For our purposes, we will mainly be using SSH to securely upload source packages to Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:126
+# 15220156465043d89c0f0a526b3ae31d
+msgid "To generate an SSH key, enter::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:130
+# 4369607909e54d2eb28b701b18832582
+msgid "The default file name usually makes sense, so you can just leave it as it is. For security purposes, it is highly recommended that you use a passphrase."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:135
+# 4709c05c499e4a29bd71f5f1aef90b23
+msgid "Set up pbuilder"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:137
+# 74362386ed8340f2b5c45b2bdb9a08da
+msgid "``pbuilder`` allows you to build packages locally on your machine. It serves a couple of purposes:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:140
+# 93aa3aaf40b44beb8662c330374e4e50
+msgid "The build will be done in a minimal and clean environment. This helps you make sure your builds succeed in a reproducible way, but without modifying your local system"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:143
+# 5169282689aa4be29c874e27633030f0
+msgid "There is no need to install all necessary *build dependencies* locally"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:144
+# c97e8554b32d4e71965f1ff6479f13b6
+msgid "You can set up multiple instances for various Ubuntu and Debian releases"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:146
+# 6a4d016f67b64cf3bbe9148306cbb3b8
+msgid "Setting ``pbuilder`` up is very easy, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:150
+# fa64536c0c324d27983772c20599b26c
+msgid "where <release> is for example `natty`, `maverick`, `lucid` or in the case of Debian maybe `sid`. This will take a while as it will download all the necessary packages for a \"minimal installation\". These will be cached though."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:156
+# 5dc23eff94724361a73a59dea44289e7
+msgid "Get set up to work with Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:158
+# 95fadc8adf9f4a0e91bac3115a3d0cf1
+msgid "With a basic local configuration in place, your next step will be to configure your system to work with Launchpad. This section will focus on the following topics:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:162
+# b79f07693785483782ed6821e0a0b9ef
+msgid "What Launchpad is and creating a Launchpad account"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:163
+# e32ac038b50b4d829f13044673ba85bc
+msgid "Uploading your GPG and SSH keys to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:164
+# 50d201d98b2747bf9b900ebd2033d4b6
+msgid "Configuring Bazaar to work with Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:165
+# 2fcbff75feec47c890b29ae9a0accc58
+msgid "Configuring Bash to work with Bazaar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:169
+# 7d3092a6e1a142afa5c22a094e2be344
+msgid "About Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:171
+# c032fdb17ad44f8a9972c7b1160387dd
+msgid "Launchpad is the central piece of infrastructure we use in Ubuntu. It not only stores our packages and our code, but also things like translations, bug reports, and information about the people who work on Ubuntu and their team memberships.  You will also use Launchpad to publish your proposed fixes, and get other Ubuntu developers to review and sponsor them."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:177
+# ad9d175d99654dad8e2c830c4beecab0
+msgid "You will need to register with Launchpad and provide a minimal amount of information. This will allow you to download and upload code, submit bug reports, and more."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:181
+# 0c25cf1d67e14ebc9621decebd78ef5c
+msgid "Besides hosting Ubuntu, Launchpad can host any Free Software project. For more information see the `Launchpad Help wiki <https://help.launchpad.net/>`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:186
+# 1060bd4edaa345a9a90d8c2e34628202
+msgid "Get a Launchpad account"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:188
+# 308e70601909430d842502f21e1589ad
+msgid "If you don't already have a Launchpad account, you can easily `create one`_. If you have a Launchpad account but cannot remember your Launchpad id, you can find this out by going to https://launchpad.net/~ and looking for the part after the `~` in the URL."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:193
+# a0e1270b66884075a0074a83105aded1
+msgid "Launchpad's registration process will ask you to choose a display name. It is encouraged for you to use your real name here so that your Ubuntu developer colleagues will be able to get to know you better."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:197
+# 7f4a08d3ce224e59b0d23ba2f4bc4b15
+msgid "When you register a new account, Launchpad will send you an email with a link you need to open in your browser in order to verify your email address. If you don't receive it, check in your spam folder."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:201
+# ff7522539ab64385b5e3460fec3e6c7f
+msgid "`The new account help page <https://help.launchpad.net/YourAccount/NewAccount>`_ on Launchpad has more information about the process and additional settings you can change."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:207
+# 8a4be4c66e1e4e4bbd19c1d319bb28bc
+msgid "Upload your GPG key to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:209
+# 506b5b99e7ac4c87ae989c190b86e41a
+msgid "To find about your GPG fingerprint, run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:213
+# 472d7ced0c4c4d6da22703585fa46fe7
+msgid "and it will print out something like::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:221
+# 0c821916735d4f45a78d52e91ef3239e
+msgid "Head to https://launchpad.net/~/+editpgpkeys and copy the \"Key fingerprint\" into the text box. In the case above this would be ``5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D``. Now click on \"Import Key\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:226
+# ec669b136a8c42269d9abfeb85d34c09
+msgid "Launchpad will use the fingerprint to check the Ubuntu key server for your key and, if successful, send you an encrypted email asking you to confirm the key import. Check your email account and read the email that Launchpad sent you. `If your email client supports OpenPGP encryption, it will prompt you for the password you chose for the key when GPG generated it. Enter the password, then click the link to confirm that the key is yours.`"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:233
+# f08b21d4e43b485194ec184975a04f7f
+msgid "Launchpad encrypts the email, using your public key, so that it can be sure that the key is yours. If your email software does not support OpenPGP encryption, copy the encrypted email's contents, type ``gpg`` in your terminal, then paste the email contents into your terminal window."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:238
+# b7455eb7f4da4959b24ef5339b994d19
+msgid "Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:241
+# 8b0f15062c314bd5bc0578ab0db7233b
+msgid "Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:245
+# c7408c90022943d2b2adb9e67b8c079d
+msgid "Upload your SSH key to Launchpad"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:247
+# d55a8885d648402ebc1c8bfa9de5b62a
+msgid "Open https://launchpad.net/~/+editsshkeys in a web browser, also open ``~/.ssh/id_rsa.pub`` in a text editor. This is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says \"Add an SSH key\". Now click \"Import Public Key\"."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:253
+# d94df3105f334f17a6b8b4493abb7237
+msgid "For more information on this process, visit the `<creating an SSH keypair <https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair>`_ page on Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:259
+# 8452a24ce68f4df6ac5e44518ef879ad
+msgid "Configure Bazaar"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:261
+# 2200087023b540598f73cba55e6d1e43
+msgid "Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently.  It is used for the new Ubuntu Distributed Development method of working with Ubuntu packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:266
+# 6809b71125db4a1c9a7039c20642d0c5
+msgid "To tell Bazaar who you are, simply run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:271
+# a7bbc2cbc2104be08887d3f357de5253
+msgid "`whoami` will tell Bazaar which name and email address it should use for your commit messages. With `launchpad-login` you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:275
+# b91245d32a2440a583e602e2b0c85ac3
+msgid "Note: If you can not remember the ID, go to https://launchpad.net/~ and see where it redirects you. The part after the \"~\" in the URL is your Launchpad ID.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:281
+# e267401effd84ebe9fad680ad51c3cd9
+msgid "Configure your shell"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:282
+# c497e7fe9aed473fac7283134a606445
+msgid "Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your `~/.bashrc` in a text editor and add something like this to the bottom of it::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:289
+# f1400dd33613411caa2495b24cb8901b
+msgid "Now save the file and either restart your terminal or run::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/getting-set-up.rst:293
+# 71fcef52c0ce4c6a9f9e098c4f35cd1a
+msgid "(If you do not use the default shell, which is `bash`, please edit the configuration file for that shell accordingly.)"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:7
+# 2b2c79c0f4744aa6ac31ab4d14510523
+msgid "Ubuntu Packaging Guide"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:9
+# 2804b34604314864a75fcd88568b92f0
+msgid "Ubuntu is not only a free and open source operating system, its platform is also open and developed in a transparent fashion. The source code for every single component can be obtained easily and every single change to the Ubuntu platform can be reviewed."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:14
+# e4717243c36b4fbaa8a4ab4731b7c6a2
+msgid "This means you can actively get involved in improving it and the community of Ubuntu platform developers is always interested in helping peers getting started."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:18
+# a8931d21f1314e2abf31996f75be3676
+msgid "The guide is split up into two sections:"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:20
+# 4432017dc60141218901d1062a4db48d
+msgid "A list of articles based on tasks, things you want to get done."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:21
+# 0d65327272d34bd094988cd9f7ec6044
+msgid "A set of knowledge-base articles that dig deeper into specific bits of our tools and workflows."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:24
+# e9691f9962684fa2983959309c708dc6
+msgid "This guide focuses on the Ubuntu Distributed Development packaging method. This is a new way of packaging which uses Distributed Revision Control branches.  It currently has some limitations which mean many teams in Ubuntu use :doc:`traditional packaging<./traditional-packaging>` methods.  See the :doc:`UDD Introduction<./udd-intro>` page for an introduction to the differences."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:31
+# 35611cc67071493d95b0fd914f093f18
+msgid "Articles"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/index.rst:46
+# 341532acc9554b0d9d4a83f5a043fdf9
+msgid "Knowledge Base"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:3
+# 795cb22fada7442f821a6d3640677ae7
+msgid "Introduction to Ubuntu Development"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:5
+# d1e2a2fc83084defb2029936d7af82db
+msgid "Ubuntu is made up of thousands of different components, written in many different programming languages. Every component -  be it a software library, a tool or a graphical application - is available as a source package. Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:14
+# d092727879c148148df7ae3a396ba4c1
+msgid "Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad's build machines to be compiled. The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in ``/etc/apt/sources.list`` point to an archive or mirror. Every day CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:24
+# 6e37b4d95d8541b7aa3011844140dfd8
+msgid "Ubuntu's development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes. Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. The rest of the cycle is supposed to be focused on fixing bugs. After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:39
+# 3095f0dc21b845bd9adafbc230310de6
+msgid "Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. This is all done in an open and transparent fashion, so even if you can not attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:51
+# c2c9a07df8734bcd84811b0d08005493
+msgid "Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:58
+# 89290a1fefbc4e5a87353e069aeb79ac
+msgid "Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:65
+# 224c0402acf54540b6e21eb5498d8bf9
+msgid "Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. These projects are called \"Upstreams\", because their source code flows into Ubuntu, where we \"just\" integrate it. The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:74
+# 7b06da07d99842fd9738c38140dd2a16
+msgid "The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:83
+# c04e0435ba0d4bb38160660e3cda4ca0
+msgid "Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:88
+# 72ea8fca34b04f5eb28aae4b06eaa638
+msgid "Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix. That is why we make use of \"Distributed Development\", where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:98
+# 38a1680f15f04e2785f959f32e8b7311
+msgid "In the example mentioned above it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:103
+# b1e0446cdaa9426cb9aa082ca826788c
+msgid "To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:112
+# fa9b32a2c49847f7b576db0fbf94036c
+msgid "When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:116
+# 471fe59800924fc88bb010d19ea956f0
+msgid "Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:119
+# f36cfc93f9314451b2f5756d1652f425
+msgid "The most important requirements for success in Ubuntu development are: having a knack for \"making things work again,\" not being afraid to read documentation and ask questions, being a team player and enjoying some detective work."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/introduction-to-ubuntu-development.rst:123
+# 7d209126020141168c019c68053e2abd
+msgid "Good places to ask your questions are ``[e-mail]`` and ``#ubuntu-motu`` on ``irc.freenode.net``. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:3
+# 993a9c1aa71f4aadadde6a86b5ef2ed3
+msgid "KDE Packaging"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:5
+# f8f58e55f37f4abcaa7264f5fdc83903
+msgid "Packaging of KDE programmes 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 about Kubuntu development is on the `Kubuntu wiki page`_."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:10
+# dc2e9c6e5402441f85737795e60858fc
+msgid "Our packaging follows the practices of the ``Debian Qt/KDE Team`` and Debian KDE Extras Team.  Most of our packages are derived from the packaging of these Debian teams."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:15
+# a38db20adbbe4a7da13b3d8559127a47
+msgid "Patching Policy"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:17
+# ac62cb4c0e664dd4b78c074e72f87171
+msgid "Kubuntu does not add patches to KDE programmes unless they come from the upstream authors or submitted upstream with the expectation they will be merged soon or we have consulted the issue with the upstream authors."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:22
+# cb2134c6ba4346458b922470c90a372f
+msgid "Kubuntu does not change the branding of packages except where upstream expects this (such as the top left logo of the Kickoff menu) or to simplify (such as removing splash screens)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:27
+# d51900d276b44514b5d0c25d00914f01
+msgid "debian/rules"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:29
+# 1311b27e75554f01874d2417d4a5b9bf
+msgid "Debian packages include some additions to the basic Debhelper usage. These are kept in the ``pkg-kde-tools`` package."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:32
+# 4bb8cca6f7f940dc84f4ea1798287277
+msgid "Packages which use Debhelper 7 should add the ``--with=kde`` option. This will ensure the correct build flags are used and add options such as handling kdeinit stubs and translations::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:39
+# 4a5e3298265c4fd4a8df97acde2c69f0
+msgid "Some newer KDE packages use the ``dhmk`` system, an alternative to ``dh`` made by the Debian Qt/KDE team.  You can read about it in /usr/share/pkg-kde-tools/qt-kde-team/2/README.  Packages using this will ``include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk`` instead of running ``dh``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:47
+# 15bc35a1eefa4bee8ed9330f9a044380
+msgid "Translations"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:49
+# ffae416394ec437c93e62703e46d4c93
+msgid "Packages in main have their translations imported into Launchpad and exported from Launchpad into Ubuntu's language-packs."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:52
+# e2265cab7d764b4b83529d3b24129102
+msgid "So any KDE package in main must generate translation templates, include or make available upstream translations and handle ``.desktop`` file translations."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:56
+# 98fc332176d84794aafa13b935d98523
+msgid "To generate translation templates the package must include a ``Messages.sh`` file; complain to the upstream if it does not.  You can check it works by running ``extract-messages.sh`` which should produce one or more ``.pot`` files in ``po/``.  This will be done automatically during build if you use the ``--with=kde`` option to ``dh``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:63
+# 931ea74ab2164fe8a5a982500456cbb2
+msgid "Upstream will usually have also put the translation ``.po`` files into the ``po/`` directory.  If they do not, check if they are in separate upstream language packs such as the KDE SC language packs.  If they are in separate language packs Launchpad will need to associate these together manually, contact `dpm`_ to do this."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:69
+# 52573e8867ac4ed2840f572b9facbcb9
+msgid "If a package is moved from universe to main it will need to be reuploaded before the translations get imported into Launchpad."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:72
+# 198ae177145b49b285220a56326dd9ce
+msgid "``.desktop`` files also need translations.  We patch KDELibs to read translations out of ``.po`` files which are pointed to by a line ``X-Ubuntu-Gettext-Domain=`` added to ``.desktop`` files at package build time.  A .pot file for each package is be generated at build time and .po files need to be downloaded from upstream and included in the package or in our language packs.  The list of .po files to be downloaded from KDE's repositories is in ``/usr/lib/kubuntu-desktop-i18n/desktop-template-list``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:82
+# b49c7bc8627b48a7b4931ebd99bb725d
+msgid "Library Symbols"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/kde.rst:84
+# a20fa5bcd911465789f7e4c2dfd61207
+msgid "Library symbols are tracked in ``.symbols`` files to ensure none go missing for new releases.  KDE uses C++ libraries which act a little differently compared to C libraries.  Debian's Qt/KDE Team have scripts to handle this. See `Working with symbols files`_ for how to create and keep these files up to date."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:3
+# 1161adad2b574c3dae7242a0e177d3cb
+msgid "Shared Libraries"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:5
+# e5417138b06748e7b459aee1467052f7
+msgid "Shared libraries are compiled code which is intended to be shared among several different programmes.  They are distributed as ``.so`` files in ``/usr/lib/``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:9
+# 3ea2eb4efb504f41812aad3d3a3630c0
+msgid "A library exports symbols which are the compiled versions of functions, classes and variables.  A library has a name called an SONAME which includes a version number.  This SONAME version does not necessarily match the public release version number.  A programme gets compiled against a given SONAME version of the library.  If any of the symbols is removed or changes then the version number needs to be changed which forces any packages using that library to be recompiled against the new version.  Version numbers are usually set by upstream and we follow them in our binary package names called an ABI number, but sometimes upstreams do not use sensible version numbers and packagers have to keep separate version numbers."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:21
+# 07915fe981c94c4db90837dba30d3cc0
+msgid "Libraries are usually distributed by upstream as standalone releases. Sometimes they are distributed as part of a programme.  In this case they can be included in the binary package along with the programme (this is called bundling) if you do not expect any other programmes to use the library, more often they should be split out into separate binary packages."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:27
+# 4c5c66ef19a44914bee41dc0539099fa
+msgid "The libraries themselves are put into a binary package named ``libfoo1`` where ``foo`` is the name of the library and ``1`` is the version from the SONAME. Development files from the package, such as header files, needed to compile programmes against the library are put into a package called ``libfoo-dev``."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:34
+# 06a1e94fcbba4e9eadba9eb114a9c642
+msgid "An Example"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:36
+# a1ec3bc9d692403ab82b43da77562aae
+msgid "We will use libnova as an example::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:41
+# cd3c9fa86411468aaf013cfabc0fdb33
+msgid "To find the SONAME of the library run"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:43
+# 0af012c44f39480b8014cfa20b67b08f
+msgid "$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:45
+# 379239ed35f840b1b788703c94ef817f
+msgid "The SONAME is ``libnova-0.12.so.2``, which matches the file name (usually the case but not always). Here upstream has put the upstream version number as part of the SONAME and given it an ABI version of ``2``.  Library package names should follow the SONAME of the library they contain. The library binary package is called ``libnova-0.12-2`` where ``libnova-0.12`` is the name of the library and ``2`` is our ABI number."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:52
+# 122c0516404646858c5e64bbaf93311e
+msgid "If upstream makes incompatible changes to their library they will have to reversion their SONAME and we will have to rename our library.  Any other packages using our library package will need to recompiled against the new version, this is called a transition and can take some effort. Hopefully our ABI number will continue to match upstream's SONAME but sometimes they introduce incompatibilities without changing their version number and we will need to change ours."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:60
+# 5bb0db11faef4045a6ffa4ff6a360ada
+msgid "Looking in debian/libnova-0.12-2.install we see it includes two files::"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:65
+# e694ef09fee449688473a2417d7e4de3
+msgid "The last one is the actual library, complete with minor and point version number.  The first one is a symlink which points to the actual library.  The symlink is what programmes using the library will look for, the running programmes do not care about the minor version number."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:70
+# 4806076bc944430598072095813eaf39
+msgid "``libnova-dev.install`` includes all the files needed to compile a programme with this library.  Header files, a config binary, the ``.la`` libtool file and ``libnova.so`` which is another symlink pointing at the library, programmes compiling against the library do not care about the major version number (although the binary they compile into will)."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:76
+# 4d4773c47d50413e9e4c9f1163445e3c
+msgid "``.la`` libtool files are needed on some non-Linux systems with poor library support but usually cause more problems than they solve on Debian systems.  It is a current `Debian goal to remove .la files`_ and we should help with this."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:82
+# 4cffd2fb14c64c8abca846161203f289
+msgid "Static Libraries"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:84
+# 6ccaf98902504122aa73d033cac53220
+msgid "The -dev package also ships ``usr/lib/libnova.a``.  This is a static library, an alternative to the shared library.  Any programme compiled against the static library will include the code directory into itself.  This gets round worrying about binary compatibility of the library.  However it also means that any bugs, including security issues, will not be updated along with the libary until the programme is recompiled.  For this reason programmes using static libraries are discouraged."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:94
+# 398bf230fe85495fb24337ec903082d5
+msgid "Symbol Files"
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:96
+# 870880e5a31c40b2a6c33ca619012e39
+msgid "When a package builds against a library the ``shlibs`` mechanism will add a package dependency on that library.  This is why most programmes will have ``Depends: ${shlibs:Depends}`` in ``debian/control``.  That gets replaced with the library dependencies at build time.  However shlibs can only make it depend on the major ABI version number, ``2`` in our libnova example, so if new symbols get added in libnova 2.1 a programme using these symbols could still be installed against libnova ABI 2.0 which would then crash."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:104
+# e6474afb8a8841ea8e5f50f6d3c97cdb
+msgid "To make the library dependencies more precise we keep ``.symbols`` files that list all the symbols in a library and the version they appeared in."
+msgstr ""
+
+#: ../ubuntu-packaging-guide/libraries.rst:107