UbuntuWiki:MOTU/School/PackagingBasicsPL

文章出处:

https://wiki.ubuntu.com/MOTU/School/PackagingBasicsPL

点击翻译:

English

请不要直接编辑翻译本页，本页将定期与来源同步。

Zanim zaczniemy

Jest mnóstwo użytecznych skrytpów i programów, które zostały utworzone aby ułatwić paczkowanie .debów. Będę korzystał z paru z nich w trakcje mojej sesji. Na początek zainstaluj: devscripts debhelper dpatch cdbs dh-make patchutils fakeroot lintian pbuilder Ponadto, byłoby bardzo wygodnie mieć pbuildera z edgy zanim zacznie się sesja: 1. Jeśli używasz edgy przejdź do kroku 2. Jeśli korzystasz z dappera ściągnij deboostrapa edgyego z packages.ubuntu.com i zainstaluj go za pomocą dpkg -i 2. Zainstaluj pbuildera sudo apt-get install pbuilder 3. Utwórz pbuildera uruchamiając:

sudo pbuilder create --distribution edgy \
	--othermirror "deb http://archive.ubuntu.com/ubuntu edgy universe multiverse"

4. Czekaj. deboostrap tworzy minimalne środowisko chroot ubuntu, więc może to potrwać trochę czasu.

IRC Log

Witaj w Szkole MOTU. Spotkania w ramach Szkoły MOTU są przygotowywane przez społeczność deweloperów Universe (MOTU) aby pomóc użytkownikom Ubuntu w zaangażowaniu się w rozwój Ubuntu. Zobacz http://wiki.ubuntu.com/MOTU aby uzyskać więcej informacji. To co przedstawię dzisiaj nie jest w żadnym stopniu wyczerpującym i pełnym podręcznikiem paczkowania. Chcę tylko przybliżyć narzędzia i techniki używane w trakcie przygotowywania i utrzymywania pakietów źródłowych. Przede wszystkim, musimy dowiedzieć się czym jest pakiet źródłowy. Pakiet źródłowy stanowią trzy różne pliki:

1. .dsc (od description - opis) plik zawierający sumy md5 pozostałych plików
2. .orig.tar.gz który jest źródłowym .tar.gz, takim samym jaki można ściągnąć ze strony projektu
3. .diff.gz który zawiera wszystkie zmiany w stosunku do .orig.tar.gz

Dziś obejrzymy sobie pewien pakiet źródłowy, plotdrop. Jest to w miarę prosty pakiet i był to mój pierwszy pakiet który zbudowałem "od zera". Na początek zróbmy katalog, w którym możemy pracować:

mkdir -p ~/motuschool/plotdrop
cd ~/motuschool/plotdrop
apt-get source plotdrop

Note 1: musisz mieć włączone repozytoria źródłowe (deb-src) w swoim /etc/apt/sources.list <
> Note 2: w przeciwieństwie do apt-get install, nie powinno się uruchamiać apt-get source przez sudo <
> OK, masz teraz trzy pliki (pakiet źródłowy) i katalog (który jest rozpakowanym pakietem źródłowym). Rozejrzyjmy się trochę:

ls plotdrop-0.5/

Widzimy, że jest to mały program w C ze standardowymi plikami (COPYING, Makefile, Changelog, itd.). Tak na prawdę, gdybyśmy rozpakowali .tar.gz ze strony plotdropa to jedyną różnicą byłby katalog debian. Jeśli chcesz, możesz zobaczyć diff (różnice) między pakietem źródłowym a oryginalnym .tar.gz za pomocą:

zless plotdrop_0.5-0ubuntu1.diff.gz

Pytanie od ubuntu_demon: Diff jest między upstream i ubuntu ? czy między debianem i ubuntu ? Odpowiedź: Między upstream (to co ściągasz ze strony domowej aplikacji) i Ubuntu albo między upstream Debianem jeśli paczkujesz dla Debiana albo gdy Ubuntu używa pakietu Debiana bez modyfikacji. Teraz wejdźmy do tego całego debian/ i zobaczmy co tam jest grane:

cd plotdrop-0.5/debian/
ls

Widzimy kilka plików i katalog patches/. Wszystkie informacje o paczkowaniu i poprawki (patche) źródła potrzebne do zrobienia .deba o dobrej jakości znajdują się właśnie tu. Musimy teraz dowiedzieć się do czego służą poszczególne pliki. Zacznijmy od changelog:

less changelog

Pierwszą rzeczą na którą warto zwrócić uwagę jest określony format changeloga. dch jest programem (który można znaleźć w pakietach devscripts), który pomaga w formatowaniu. W pierwszej linii znajdziesz nazwę pakietu, jego wersję i wydanie (release). Za każdym razem, gdy nowy pakiet źródłowy jest uploadowany do maszyn budujących pakiety Ubuntu powinien mieć on wyższą wersję niż poprzedni. Wersja wygląda tak: (wersja programu)-(rewizja debiana)ubuntu(rewizja ubuntu) W tym przypadku wersja programu to 0.5, rewizja Debiana to 0, bo wtedy plotdropa nie było w Debianie, a rewizja ubuntu to 1. Pytanie od FLeiXiuS: To nie jest zautoamtyzowane przez dch, prawda? Odpowiedź: dch tworzy tylko szablon Pytanie od redguy: co się dzieje gdy pakiet zostaje włączony do debiana? Odpowiedź: rewizja debiana zmienia się na 1, np. 0.5-1 Pytanie od neutrinomass: Obecna wersja pakietu źródłowego kdeadmin to "4:3.5.4-0ubuntu2 " . Co oznacza '4:' ? Odpowiedź: To się nazywa epoch (epoka?) i jest używane, gdy wersjonowanie upstream się zmieniło lub gdy są błędy w wersjach pakietu. Zapewnia to, że nowszy pakiet zostanie zainstalowany nawet gdy sposób wersjonowania się zmienił. Zobacz http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version po więcej informacji. Pytanie od matid: Czy jest możliwe dopisywać od aktualnego changeloga za pomocą dch? Odpowiedź: Tak. Zerknij na man dch aby dowiedzieć się o opcjach. Pytanie od gnube: Czy w Ubuntu są pakiety, których nie ma w debianie? Odpowiedź: Tak. Jeśli pakiet nie jest w Debianie wtedy rewizja Debiana = 0. Jeśli pakiet nie wymaga żadnych zmian (co bardzo lubimy) pozostawiamy wersję z Debiana. Zmieniamy wersję tylko wtedy gdy potrzebujemy. Ok, wróćmy do pliku changelog . Poniżej widzimy różne wpisy opisujące co się zmieniło między starszą i nowszą wersją i na końcu widzimy linię "kto to zrobił" która zawiera informacje o tym kto i kiedy dokonał tych zmian. Warto zwrócić tutaj uwagę na to, że imię, nazwisko i adres e-mail są ważne i są potrzebne do tego aby wyśledzić kto co zrobił, a jeśli zamierzasz podpisać cyfrowo pakiet to konieczne jest upewnić się, że adres e-mail jest taki sam jak w twoim kluczu gpg, ale o tym później. Ok, przejdźmy do pliku control:

less control

Plik control przechowuje informacje o pakiecie źródłowym i wynikowym pakiecie binarnym (.deb). Ma on strukturę pole: wartość. Większość pól ma dość oczywiste nazwy ale wartości, co zaraz się okaże, są trudniejsze do określenia. Dla pakietu źródłowego mamy:

• Source: nazwa pakietu źródłowego
• Section: do jakej sekcji repozytorium należy program
• Priority: czy pakiet jest wymagany do poprawnie działającego systemu Linux?
• Maintainer: kto jest odpowiedzialny za pakiet, używane głównie w Debianie
• Build-Depends: pakiety, które muszą być zainstalowane aby z pakietu źródłowego mógł powstać .deb
• Standards-Version: wersja Debian Policy, z którą jest zgodny ten pakiet

Jest możliwych więcej pól ale te można znaleźć w prawie wszystkich pakietach. Przeczytaj Debian Policy aby uzyskać więcej informacji: http://www.debian.org/doc/debian-policy/ch-source.html i http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles Wiedz, że Priority nie jest dowolne, możesz użyć tylko wybranych wartości, które są opisane w Debian Policy i w Ubuntu Packaging Guide Pytanie od gnube: Nieprawidłowo sformatowany plik control może być przyczyną problemów, prawda? Odpowiedź: Tak, pakiet nie zbuduje się. Pliki do paczkowania są często czytane przez różne skrypty więc zachowanie odpowiedniego formatowania jest istotne. Pytanie od gnube: Czy jest zautomatyzowane narzędzie pozwalające określić Build-Depends ? Odpowiedź: Raczej nie. Jest kilka skryptów, które mogą pomóc, ale generalnie trzeba wymyślić czego program potrzebuje aby zostać zbudowany i dodać to do Build-Depends. Powiedzmy, że program używa GTK - potrzebuje wtedy libgtk2.0-dev w Build-Depends żeby skompilował się poprawnie. Dobrym pomysłem jest przeczytanie pliku README w źródłowym .tar.gz przeczytanie informacji na stronie domowej projektu. Dla pakietu binarnego mamy:

• Package: nazwa pakietu binarnego, może być więcej niż jeden pakiet binarny na jeden pakiet źródłowy więc musisz to określić
• Architecture: na jakiej (i dla jakiej) architekturze plik binarny będzie się budował. "any" znaczy że powinien się zbudować na wszystkich architekturach a "all" znaczy że nie ma żadnych plików zależnych od architektury (np. program napisany w interpretowanym języku takim jak python)
• Depends: pakiety od których zależy pakiet binarny
• Description: Pierwsza linia zawiera krótki opis. Kolejne linie zawierają długi opis. Zwróć uwagę na spację na początku każdej z linii długiego opisu, są one istotne.

Znowu, powyższe jest w miarę jednoznaczne (self explainitory). OK, przejdźmy na chwilkę do compat. Plik compat ma tylko liczbę całkowitą która odpowiada wersji debhelpera (pakietu pomocniczego, o którym pomówimy później). W tym wypadku, skoro mieliśmy Build-Depends: debhelper >= 4.0.0 , compat zawiera liczbę 4 . Przenieśmy się do pliku copyright. Ten plik jest bardzo ważny dla nas, dystrybucji open source, ponieważ zawiera on informację o prawie autorskim i licencji dla wszystkich plików pakietu źródłowego. Powinny się tam znaleźć:

1. skąd pobrano źródłowy .tar.gz
2. kto jest właścicielem praw autorskich do źródłowego .tar.gz
3. licencja, na warunkach której możemy dystrybuować kod

Dla popularnych licencji takich jak GPL możesz umieścić tylko preambułę i informację o tym, że pełny tekst licencji można znaleźć w /usr/share/common-licenses . Jeśli licencja *nie* jest jedną z tych umieszczonych w /usr/share/common-licenses musisz umieścić *cały* tekst licencji. Częstym błędem paczkującego jest uwierzyć stronie domowej projektu jeśli chodzi o licencję. Paczkujący musi upewnić się, że kod źródłowy zawiera informacje o licencjonowaniu i że dotyczy ona wszystkie pliki zawarte w źródłowym .tar.gz . Często zapomina się o dokumentacji i o grafice/dźwiękach itp. (które są często na innej licencji niż sam kod). Pytanie od matid: Co jeśli różne części programu, który chcemy zbudować, są objęte różnymi licencjami? Odpowiedź: Musisz wypisać wszystkie z nich. Które pliki objęte są daną licencją i jeśli jedna z nich nie jest w/usr/share/common-licenses musisz załączyć jej cały tekst. Sprawdź również, czy są kompatybilne gdy są wykorzystane jednocześnie (przykład: licencje GPL i OpenSSL) Jest to dość uciążliwe i zdaje się niezbyt ważne, ale dla Ubuntu koniecznością jest pewność, że legalnie rozpowszechniamy kod. Są tysiące pakietów w Debianie/Ubuntu i wielokrotnie ludzie pytają "czemu XYZ nie jest w Ubuntu?" i często jest to spowodowane problemami z licencją. Pytanie od ubuntu_demon: Czy jest jakieś zalecane miejsce, gdzie można się udać z pytaniami o licencje ? Odpowiedź: Jeśli nie masz pewności co do licencji poszukaj w archiwach listy mailingowej debian-legal i sprawdź Debian Free Software Guidelines. Ubuntu nie posiada zespołu prawnego jako takiego, polegamy głównie na Debian Legal i naszych znakomitych adminów archiwów. Dobrze jest zachęcać autorów oprogramowania do używania dobrej (wolnej w sensie DFSG) licencji. Czasami powiedzenie "Twój program wymiata, chcę włączyć go do Ubuntu ale nie mogę ze względu na licencję" wystarcza aby nakłonić kogoś do zmiany licencji. Teraz pobawmy się z esencją pakietu źródłowego - plikem rules.

less rules

Plik rules jest plikiem typu Makefile, który jest uruchamiany przez dpkg-buildpackage aby zbudować .deba . Nie będę wnikał w wiele szczegółów bo nie ma na to czasu, ale zwróć uwagę na różne reguły (clean, build, install itp.) a także na to, że nie istalujemy w / $(CURDIR)/debian/plotdrop/ . To może być kłopotliwe dla ludzi na początku. Wszystkie dh_* są skryptami będącymi częścią debhelpera, który jest zestawem narzędzi ułatwiającym budowanie pakietów (pamiętaj, że mieliśmmy zależność od debhelpera w control). Każdy z nich ma określone zadanie (zazwyczaj można się go domyślić z nazwy) maja one też dobre strony man więc dobrym pomysłem jest zerknąć na podręcznik każdego z nich żeby zobaczyć co robią. Jedną z rzeczy, której dowiesz się o paczkowaniu jes to, że zazwyczaj jest więcej niż jeden sposób na wykoanie jednej rzeczy. Deweloparzy Debiana lubią pisać skryptu i automatyzować różne rzeczy więc dla debian/rules :

1. możemy nie używać żadnego systemu skryptów pomocniczych i ręcznie uruchamiać wszystkie polecenia jak w zwykłym Makefile
2. możemy użyć debhelpera (tak jak w tym przypadku) aby zautomatyzować pewne zadania (dh_install instaluje pliki)
3. możemy użyć CDBS (common debian build system - wspólny? system budowania debiana), który jest jeszcze bardziej zautomatyzowanym systemem i wynikowy plik debian/rules miałby zaledwie kilka linii

Ogólnie dobrze nie używać 1) bo 2) i 3) działają dobrze, w większości przypadków, ale ważne jest wiedzieć co automatyzacja w 2) i 3) na prawdę robi. Pytanie od ubuntu_demon: używanie CDBS jest łatwiejsze niż debhelpera? Odpowiedź: Może być, ale nie w każdym przypadku. Niektórzy paczkujący unikają CDBS bo wydaje się on magiczną czarną skrzynką, ale jeśli masz zaparcie i na prawdę zrozumiesz co CDBS robi to możesz sobie mocno uprościć debian/rules. Widziałem pliki debian/rules, które zawierały jedną linię. Polecam jednak naukę debhelpera przed używaniem CDBS, bo CDBS jest mniej więcej zautomatyzowanym debhelperem. Pytanie od matid: W jakiej sytuacji może być konieczna ręczna modyfikacja debian/rules po uruchomieniu debhelpera? Odpowiedź: debhelper tylko zbiorem skryptów dh_*. Więc na przykład dh_strip stripuje symbole do debugowania z binarek (strips debugging symbols from the binaries), dh_installman instaluje strony man, a dh_python dodaje do skryptu postinst elementy które mają zostać skompilowane to bajtkodu pythona na maszynie użytkownika. Dlatego ważne jest aby przeczytać stronę man każdego z używanych skryptów auby upewnić się, że potrzebujesz tego co dany skrypt robi i że używasz go poprawnie. Pytanie od matid: Ok, ale dh_make tworzy plik rules, czyż nie? Answer: Tak, szablon pliku rules. dh_make używa się aby powstał szablon katalogu debian/ . Większości z plików które dh_make tworzy nie jest potrzebnych, w szczególności pliki .ex . Jest dość sporo skryptów mających za zadanie pomóc (dh_make, dch, debhelper, etc.) ale w końcu, to twoim zadaniem jest upewnienie się co w debian/ jest poprawne a co nie. dh_make może dać dobre przybliżenie i szablon do wypełnienia ale nie zakładaj, że wstawi on wszystkie poprawne wartości za ciebie ;-) Paczkowanie jest dość skomplikowane ale można się go z odrobiną wysiłku i pomocy od MOTU nauczyć. Gdy już się przyzwyczaisz nie jest tak źle. Jest po prostu sporo spraw, które trzeba mieć na uwadze. To właśnie to sprawia, że Debian i dystrybucje oparte na Debianie są tak solidne. Nie mogę podać przepisu na pisanie debian/rules. Robi się to wiedząc co należy zrobić aby zbudować program, który paczkujesz. W większości przypadków, jeśli twój program "jest grzeczny", szablon wygenerowany przez dh_make jest dość zbliżony do ostatnecznego pliku rules, ale jeśli musisz wykonać sporo zmian żeby się zbudował i był zgodny z Debian Policy najprawdopodobniej trochę go zmodyfikujesz. Ważne pamiętać co każdy z elementów debian/rules robi. Na przykład - czy potrzebujesz dh_strip jeśli nie masz żadnych binarek? Pytanie od oly: Czy można budować pakiety programów, które nie wymagają budowania? Odpowiedź: Oczywiście, paczkujemy nawet dokumentację i artwork, które w ogóle nie zawierają kodu. Po prostu pozostaw regułe build: pustą, nie ma przecież niczego do budowania. Pytanie od redguy: Co jeśli Makefile z upstream nie rozumie --prefix i instaluje skompilowane binarki do jakiegoś ustalonego katalogu. Czy paczkujący powinien zmodyfikować Makefile z upstreamu, czy użyć reguły install: żeby zainstalować program do debian/nazwa_pakietu? Odpowiedź: Wtedy robisz patcha do Makefile. Najlepiej by było, jeśli skontaktujesz się z autorem i dowiesz się, czy może on dostarczyć Makefile, które rozumie --prefix. Ok, so we've seen most of the core of the packaging. If we look around we see plotdrop.1 which is a man page. I had to make the man page because the author didn't provide one. Even though this is a GUI app, anything that goes in /usr/bin should have a man page. We see plotdrop.manpages, which is a file that tells dh_installman what man page to install. plotdrop.menu is a Debian menu file. Debian has it's own menu system (which Ubuntu doesn't use) but as I wanted this package to also go into Debian I added it. dirs is a file that has the directories that need to be created when running rules that aren't created by the program's Makefile Question from matid: What about Ubuntu? Will plotdrop create a menu entry in Ubuntu? Answer: Yes, it installs a .desktop file which is the freedesktop.org standard for menu files which Gnome, KDE, and XFCE adhere to. Whenever you do work for Ubuntu think about whether the work is Ubuntu specific or not. If it is not make sure to push that work on upstream (either to Debian if it is packaging, or the authors if it is bug fix code, etc.) Question from matid: So it's possible to create a package that installs a menu entry in both debian and ubuntu, whichever it's installed in? Answer: It will actually go into both the Debian menu and the Gnome/KDE/XFCE/etc. menu

Let's look at the patches directory, 01_Makefile.dpatch is a patch that I made to the programs Makefile because it's PREFIX was hardocoded and it didn't want to install to

/debian/plotdrop/ . What I did is rather than just modifying the Makefile and having it show up as a diff in the .diff.gz I used a patch system called <code><nowiki>dpatch</nowiki></code>. It is called in the debian/rules file and patches at build time, that way I can seperate patches by purpose. So if upstream "fixes" the problem that I need the patch for I can easily get rid of it. Which has actually happened in this case, so in the next version I can drop that patch easily.
''Question from matid:'' Is it ok to use dpatch ever for, let's say - typos in the package's description?
''Answer:'' You don't need to use patches for changing files in ''debian/'' as that is part of the packaging. The purpose of the patch systems is to seperate what we have done from the author's code so someone can clearly and easily see what we have changed.
If you want to learn more about patch systems I'll refer you to pitti's excellent MOTU School session: [[UbuntuWiki:MOTU/School/PatchingSources|MOTU/School/PatchingSources]].
OK, now let's have some fun:
<pre><nowiki>
cd debian/
dch -i
</nowiki></pre>
This open up ''changelog'' in your favorite text editor (you can set EDITOR in your .bashrc or use <code><nowiki>update-alternatives</nowiki></code>) with a new template changelog entry. The thing to keep in mind is to make sure to check that the versioning is correct (it won't add the ubuntu versioning if it didn't exist already) and make sure to check the release (dapper, edgy, etc.) to make sure it is the one you are targetting the source package for.
''Question from ubuntu_demon:'' how do you change the name and e-mail address for the template ?
''Answer:'' You can set the DEBFULLNAME and DEBEMAIL environment variables, in .bashrc for instance. Also make sure that they are the same as the info in your GPG key.
My new changelog entry looks like this:
<pre><nowiki>
plotdrop (0.5-0ubuntu2) edgy; urgency=low

   * Blah blah blah

  -- Jordan Mantha <[email protected]>  Thu, 10 Aug 2006 18:54:14 -0700
</nowiki></pre>
OK, so once you have saved ''changelog'' go up to the source dir:
<pre><nowiki>
cd ..
</nowiki></pre>
Now we are going to build a new source package since we made a change ;-)
<pre><nowiki>
debuild -S
</nowiki></pre>
or if you don't have a gpg key run:
<pre><nowiki>
debuild -S -us -uc
</nowiki></pre>
and if you have a gpg key but debuild -S doesn't work use:
<pre><nowiki>
debuild -S -k<yourkeyid>
</nowiki></pre>
What this does is:
* runs the clean: rule in ''debian/rules''
* creates a new diff.gz with the changes you've made
* runs <code><nowiki>lintian</nowiki></code>, which is a helper app that finds common mistakes
* and creates the new .dsc and signs it if you have a gpg key
Now you can go up a dir again
<pre><nowiki>
cd ..
</nowiki></pre>
and now you have a new source package:
* plotdrop_0.5-0ubuntu2.dsc
* plotdrop_0.5-0ubuntu2.diff.gz
* plotdrop_0.5.orig.tar.gz (which hasn't changed)
The ''plotdrop_0.5-0ubuntu2_source.build'' file has the source package build log and the ''plotdrop_0.5-0ubuntu2_source.changes'' file is a file that is used to upload the source package (it contains the md5sums of all the package files)
One thing that is useful is creating a debdiff:
<pre><nowiki>
debdiff plotdrop_0.5-0ubuntu1.dsc plotdrop_0.5-0ubuntu2.dsc \
 > plotdrop_0.5-0ubuntu2.debdiff
</nowiki></pre>
A debdiff is what a MOTU would like to see attached to a bug report. It's much smaller than uploading the whole package somewhere, is only one file, and it allows you to see small changes easily. In this case we just have the changelog entry
Now we probably want to build a .deb to make sure everything went ok and files go where they are supposed to and that installation works, etc. This is where <code><nowiki>pbuilder</nowiki></code> comes in. You '''can''' build the .deb using <code><nowiki>debuild</nowiki></code> but you aren't sure if your dependecies are right and you might be running dapper and want to build a .deb for edgy. <code><nowiki>pbuilder</nowiki></code> uses <code><nowiki>debootstrap</nowiki></code> to create a clean chroot environment which is a very  minimal Ubuntu install. In fact it has the same packages that the Ubuntu build machines have so if a package builds with pbuilder it should also build in the Ubuntu build machines.
Instructions for setting up a pbuilder are at the top of the page, in the Packaging Guide (help.ubuntu.com) and on the Wiki (wiki.ubuntu.com/PbuilderHowto)
If you have a pbuilder created run:
<pre><nowiki>
sudo pbuilder build plotdrop_0.5-0ubuntu2.dsc
</nowiki></pre>
and it will unpack the pbuilder chroot and build the .deb inside of that. When it's done it will clean the environment and spit out the .deb to ''/var/cache/pbuilder/result/''
''Question from matid:'' Is it possible to build 2 packages at the time?
''Answer:'' Yeah, it'll be slow, but it will unpack the pbuilder environment to a different temp directory.
''Question from oly:'' will the package also work in dapper even though we are building it with edgy in mind ?
''Answer:'' Not necessarily. You would want to create a dapper pbuilder for that. For instance, on my machine I have breezy, dapper, edgy, Debian unstable, and Debian stable pbuilders. If the dependecies haven't changed then you can get away with it.
''Question from ubuntu_demon:'' Creating a backport (edgy to dapper) is just a matter of changing the dependencies and replacing dapper for edgy in the changelog right ?
''Answer:'' In fact, the simplest backport would be to just build the edgy source package in a dapper pbuilder but sometimes the deps change name or version and then you have to change debian/control.
''Question from redguy:'' Do the packages downloaded by pbuilder get cached somewhere?
''Answer:'' Yes. Pbuilder often has to download a lot of packages. It keeps an apt cache outside the pbuilder to keep the packages around for later use. However, the pbuilder is unpacks the base.tgz (compress chroot) each time you build with it so it stays clean.
''Question from redguy:'' why do I have to install the edgy deboostrap in order to make the edgy pbuilder?
''Answer:'' Because each release has a deboostrap script that tells it what packages to get so the edgy debootstrap has scripts for all previous Debian and Ubuntu releases. But since the devs didn't know in Dapper what Edgy would be they couldn't add an edgy script into dapper's debootstrap package.
You can also create chroot environments to test in using <code><nowiki>dchroot</nowiki></code>. I have chroots for dapper, edgy, and Debian unstable on my dapper box. So if I create a .deb for one of those I can test it inside a chroot. [[UbuntuWiki:DebootstrapChroot|DebootstrapChroot]] is a wiki page that describes setting up a chroot.
For people who don't have pbuilder up yet you can grab the .deb at 
http://packages.ubuntu.com/edgy/math/plotdrop
What we want to do is check to make sure that the packages go where we want them to, or expect them to at least. To do that you can run <code><nowiki>dpkg -c</nowiki></code> on the .deb and it will spit out the list of files that will be installed.
''Question from matid:'' Do we have to manually run lintian -i plotdrop_0.5-0ubuntu2.dsc? It's not automatic, is it?
''Answer:'' Well, it is run during debuild -S but the -i flag gives you more info and you can also run lintian on the .deb to see if it sees a problem with the binary.
''Question from redguy:'' Actually lintian is complaining when I run <code><nowiki>debuild -S</nowiki></code> - "changelog-should-mention-nmu". What does nmu stand for?
''Answer:'' NMU is Non-Maintainer Upload and is Debian specific. In Debian each package has a specific maintainer or maintainers and other developers are not supposed to just change another maintainer's package but sometimes it is needed (a release critical bug fix and the maintainer is out of town or something). For a NMU you use a differnent version and put NMU in the changelog, but Ubuntu doesn't have maintainership like Debian. In Ubuntu any MOTU can upload any Universe package, we work as a team.
If you run <code><nowiki>dpkg -e</nowiki></code> on the .deb it will extract the control info into ''./DEBIAN''
. In this case it contains the ''control'' file, which has all the Dependencies. You can make sure that everything is ok there. Also the ''postinst'' (post install) and ''prerm'' (pre remove) scripts.
''Question from ranf:'' What's FTBFS?
''Answer:'' Fails To Build From Source, this is what we call source packages that fail to build.
=== The End ===
Ok, so I want to encourage everybody to contribute to Ubuntu. Here are some resources:
* Ubuntu Packaging Guide http://help.ubuntu.com
* Debian Developer docs http://www.debian.org/devel/
* MOTU Wiki http://wiki.ubuntu.com/MOTU
* MOTU Mentors program (getting involved with MOTU) http://wiki.ubuntu.com/MOTU/Mentors
* REVU (MOTU review server where anybody can upload) http://wiki.ubuntu.com/MOTU/Packages/REVU
* #ubuntu-motu and #ubuntu-motu-school on irc.freenode.net
To start contributing you need to have a GPG key (https://help.ubuntu.com/community/GnuPrivacyGuardHowto if you need help there) and a Launchpad account. Then join the revu-uploaders Launchpad team (https://launchpad.net/people/revu-uploaders) and then upload to REVU (see the REVU wiki page for details) which is at http://revu.tauware.de . You package will be reviewed by MOTUs. If it is a brand new package it will need to get 2 votes to enter Universe.

[[category:UbuntuWiki]]