0 - en to nb-NO translation catalogue (190 entries)

en: Backport
nb-NO: Bakdør

en: Rebuild
nb-NO: Gjenoppbygge

en: Source package
nb-NO: Kildepakke

en: Archive
nb-NO: Arkiv

en: Meta-package
nb-NO: Meta-pakke

en: Debian Developer
nb-NO: Debian-utvikler

en: Debian Package
nb-NO: Debian-pakke

en: Maintainer
nb-NO: Vedlikeholder

en: Creating a Debian Package
nb-NO: Hvordan lage en Debian-pakke

en: It is quite common, for an administrator who has been handling Debian packages in a regular fashion, to eventually feel the need to create their own packages, or to modify an existing package. This chapter aims to answer the most common questions in this field, and provide the required elements to take advantage of the Debian infrastructure in the best way. With any luck, after trying your hand for local packages, you may even feel the need to go further than that and join the Debian project itself!
nb-NO: Det er nokså vanlig for en administrator som har håndtert Debian-pakker jevnlig å etter hvert ønske å lage egne pakker, eller modifisere en eksisterende pakke. Dette kapittelet tar sikte på å svare på de vanligste spørsmålene på dette området, og gi nødvendige instrukser for å utnytte Debians infrastruktur på beste måte. Med litt flaks, etter å ha prøvd deg fram med lokale pakker, kan du kanskje til og med tenke deg å gå lengre, og bli med i Debian-prosjektet selv!

en: Rebuilding a Package from its Sources
nb-NO: Å bygge en pakke på nytt fra kildekoden

en: <primary>package</primary><secondary>rebuild</secondary>
nb-NO: <primary>pakke</primary><secondary>bygge på nytt</secondary>

en: Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as <emphasis role="distribution">Testing</emphasis> or even <emphasis role="distribution">Unstable</emphasis> — so that this new package works in their <emphasis role="distribution">Stable</emphasis> distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information. <ulink type="block" url="https://tracker.debian.org/" /> <indexterm><primary>backport</primary></indexterm>
nb-NO: Å bygge en binær pakke på nytt er nødvendig under flere omstendigheter. I noen tilfeller trenger administratoren en programvarefunksjon som krever at programvaren som skal kompileres fra kildekoden med et spesielt kompileringsalternativ; i andre er programvaren som er pakket i den installerte versjonen av Debian ikke ny nok. I det sistnevnte tilfellet vil administratoren vanligvis bygge en nyere pakke tatt fra en nyere versjon av Debian - så som <emphasis role="distribution">Testing</emphasis>, eller til og med <emphasis role="distribution">Unstable</emphasis> - slik at denne nye pakken virker i deres <emphasis role="distribution">Stable</emphasis>-distribusjon: Denne operasjonen kalles «backporting». Som vanlig bør man være forsiktig før en tar på seg en slik oppgave, og først sjekke om den har blitt gjort allerede: Ta en rask titt på Debians pakkesporer for å se om pakken kan vise informasjon om det. <ulink type="block" url="https://tracker.debian.org/" /> <indexterm><primary>backport</primary></indexterm>

en: Getting the Sources
nb-NO: Henting av kildekode

en: <primary>package</primary><secondary>source</secondary>
nb-NO: <primary>pakke</primary><secondary>kildekode</secondary>

en: Rebuilding a Debian package starts with getting its source code. The easiest way is to use the <command>apt-get source <replaceable>package-name</replaceable></command> command. This command requires a <literal>deb-src</literal> line in the <filename>/etc/apt/sources.list</filename> file, and up-to-date index files (i.e. <command>apt-get update</command>). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see <xref linkend="sect.apt-sources.list" />). Note, however, that you will be downloading the source packages from the Debian version mentioned in the <literal>deb-src</literal> line.
nb-NO: Å gjenoppbygge en Debian-pakke starter med å hente kildekoden. Den enkleste måten er å bruke kommandoen <command>apt-get source <replaceable>pakkenavn</replaceable></command>. Slik bruk krever en <literal>deb-src</literal>-linje i filen <filename>/etc/apt/sources.list</filename>, og en oppdatert oversikt over pakkebrønnsfiler (f.eks. ved bruk av <command>apt-get update</command>). Disse forutsetningene bør allerede være på plass hvis du har fulgt instruksen i kapitlet som har med APT-oppsett å gjøre (sjekk <xref linkend="sect.apt-sources.list" />). Merk at du laster ned kildepakkene fra Debian-versjonen nevnt i<literal>deb-src</literal>-linjen.

en: If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions <filename>*.dsc</filename> — for <emphasis>Debian Source Control</emphasis> — <filename>*.tar.<replaceable>comp</replaceable></filename>, and sometimes <filename>*.diff.gz</filename> or <filename>*.debian.tar.<replaceable>comp</replaceable></filename> — <replaceable>comp</replaceable> taking one value among <literal>gz</literal>, <literal>bz2</literal> or <literal>xz</literal> depending on the compression tool in use), then run the <command>dpkg-source -x <replaceable>file.dsc</replaceable></command> command. If the <filename>*.dsc</filename> file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the <command>dget <replaceable>URL</replaceable></command> command. This command (which can be found in the <emphasis role="pkg">devscripts</emphasis> package) fetches the <filename>*.dsc</filename> file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using <command>dscverify</command>, and it extracts the source package (unless the <literal>-d</literal> or <literal>--download-only</literal> option is used). The Debian keyring is needed, unless the option <literal>-u</literal> is supplied.
nb-NO: Hvis du trenger en annen versjon, må du kanskje laste den ned manuelt fra et Debian-speil, eller fra nettstedet. Dette innebærer henting av to eller tre filer (med utvidelser <filename>*.dsc</filename> - for <emphasis>Debian Source Control</emphasis> - <filename>*.tar.<replaceable>comp</replaceable></filename>, og noen ganger <filename>*.diff.gz</filename> eller <filename>*.debian.tar.<replaceable>comp</replaceable></filename> - <replaceable>comp</replaceable> som tar en verdi blant <literal>gz</literal>, <literal>bz2</literal> eller <literal>xz</literal>, avhengig av kompresjonsverktøyet som ble bruk), kjør deretter <command>dpkg-source -x <replaceable>file.dsc</replaceable></command>-kommandoen. Hvis <filename>*.dsc</filename>-filen er tilgjengelig direkte fra en gitt URL, er det til og med enklere vei å få tak i alt sammen, med <command>dget <replaceable>URL</replaceable></command>-kommandoen. Denne kommandoen (som er en del av pakke <emphasis role="pkg">devscripts</emphasis>) fanger opp <filename>*.dsc</filename>-filen på den gitte adressen, så analyserer den innholdet, og filen eller filene det refereres til hentes automatisk. Når alt er lastet ned, verifiseres integriteten til den nedlastede kildekoden ved å bruke <command>dscverify</command>, og det pakker ut kildekoden (om ikke <literal>-d</literal> eller <literal>--download-only</literal>-valget er benyttet). Debian nøkkelring behøves om ikke valget <literal>-u</literal> foreligger.

en: Making Changes
nb-NO: Hvordan gjøre endringer

en: Let us use the <emphasis role="pkg">samba</emphasis> package as an example.
nb-NO: La oss bruke <emphasis role="pkg">samba</emphasis>-pakken som et eksempel.

en: The source of the package is now available in a directory named after the source package and its version (<filename>samba-4.13.13+dfsg</filename>); this is where we'll work on our local changes.
nb-NO: Pakkekilden er tilgjengelig i en katalog oppkalt etter kildepakkens versjon (<filename>samba-4.13.13+dfsg</filename>): Dette er der vi skal jobbe med våre lokale endringer.

en: The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is <literal>2:4.13.13+dfsg-1~deb11u3</literal>, we can create version <literal>2:4.13.13+dfsg-1~deb11u3+falcot1</literal>, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the <command>dch</command> command (<emphasis>Debian CHangelog</emphasis>) from the <emphasis role="pkg">devscripts</emphasis> package. <indexterm><primary><command>dch</command></primary></indexterm> <indexterm><primary><emphasis role="pkg">devscripts</emphasis></primary></indexterm> <indexterm><primary>package</primary><secondary>version</secondary></indexterm>
nb-NO: Det første du må gjøre er å endre pakkens versjonsnummer, slik at de nye pakkene kan skilles fra de opprinnelige pakkene som følger med Debian. Forutsatt at gjeldende versjon er <literal>2:4.13.13+dfsg-1~deb11u3</literal>, kan vi lage versjon <literal>2:4.13.13+dfsg-1~deb11u3falcot1</literal>, som tydelig viser opprinnelsen av pakken. Dette gjør pakkens versjonsnummer høyere enn den som tilbys av Debian, slik at pakken lett vil installeres som en oppdatering til den opprinnelige pakken. En slik endring er best utført med <command>dch</command>-kommandoen (<emphasis>Debian CHangelog</emphasis>) fra <emphasis role="pkg">devscripts</emphasis>-pakken. <indexterm><primary><command>dch</command></primary></indexterm> <indexterm><primary><emphasis role="pkg">devscripts</emphasis></primary></indexterm> <indexterm><primary>package</primary><secondary>version</secondary></indexterm>

en: The last command invokes a text editor (<command>sensible-editor</command> — this should be your favorite editor if it is mentioned in the <varname>VISUAL</varname> or <varname>EDITOR</varname> environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that <command>dch</command> really did change the <filename>debian/changelog</filename> file.
nb-NO: Den siste kommandoen kaller et tekstredigeringsprogram (<command>sensible-editor</command> — dette bør være ditt favoritt-tekstredigeringsprogram hvis det er nevnt i <varname>VISUAL</varname> eller <varname>EDITOR</varname>-miljøvariablene, og forvalgt tekstredigeringsprogram ellers) for å tillate dokumentering av forskjellene som er forårsaket av denne gjenoppbyggingen. Dette skriveprogrammet viser oss at <command>dch</command> virkelig har endret <filename>debian/changelog</filename>-filen.

en: <primary>environment variable</primary><secondary><varname>VISUAL</varname></secondary>
nb-NO: <primary>miljøvariabel</primary><secondary><varname>VISUAL</varname></secondary>

en: <primary>environment variable</primary><secondary><varname>EDITOR</varname></secondary>
nb-NO: <primary>miljøvariabel</primary><secondary><varname>EDITOR</varname></secondary>

en: <primary>package</primary><secondary><filename>changelog</filename></secondary>
nb-NO: <primary>pakke</primary><secondary><filename>changelog</filename></secondary>

en: <primary><command>dh</command></primary><secondary>override target</secondary>
nb-NO: <primary><command>dh</command></primary><secondary>overstyr mål</secondary>

en: <primary>package</primary><secondary><filename>rules</filename></secondary><seealso><filename>rules</filename></seealso>
nb-NO: <primary>pakke</primary><secondary><filename>rules</filename></secondary><seealso><filename>rules</filename></seealso>

en: Depending on the local changes to the packages, an update may also be required in the <filename>debian/control</filename> file, which contains a description of the generated packages. In particular, this file contains <literal>Build-Depends</literal> lines controlling the list of dependencies that must be fulfilled at package build time. These often refer to versions of packages contained in the distribution the source package comes from, but which may not be available in the distribution used for the rebuild. There is no automated way to determine if a dependency is real or only specified to guarantee that the build should only be attempted with the latest version of a library — this is the only available way to force an <emphasis>autobuilder</emphasis> to use a given package version during build, which is why Debian maintainers frequently use strictly versioned build-dependencies.
nb-NO: Avhengig av de lokale endringene i pakkene, kan en oppdatering også være nødvendig i <filename>debian/control</filename>-filen, som inneholder en beskrivelse av de genererte pakker. Spesielt inneholder denne filen <literal>Build-Depends</literal>-linjer som kontrollerer listen over avhengigheter som må være oppfylt når pakken bygges. Disse refererer ofte til versjonene til pakkene i distribusjonen som kildepakken kommer fra, men som kanskje ikke er tilgjengelig i distribusjonen som brukes til ombygging. Det er ingen automatisk måte å avgjøre om en avhengighet er ekte, eller bare spesifisert til å garantere at bygget kun skal bli forsøkt med den nyeste versjonen av et bibliotek - dette er den eneste tilgjengelige måten å tvinge en <emphasis>autobuilder</emphasis> til å bruke en gitt pakkeversjon under oppbyggingen, og det er derfor Debians vedlikeholdere ofte bruker strenge versjonsbestemte byggeavhengigheter.

en: <primary>package</primary><secondary><filename>control</filename></secondary><see><filename>control</filename></see>
nb-NO: <primary>pakke</primary><secondary><filename>control</filename></secondary><see><filename>control</filename></see>

en: <primary><filename>control</filename></primary><secondary><literal>Build-Depends</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Build-Depends</literal>, hodefelt</secondary>

en: If you know for sure that these build-dependencies are too strict, you should feel free to relax them locally. Reading the files which document the standard way of building the software — these files are often called <filename>INSTALL</filename> — will help you figure out the appropriate dependencies. Ideally, all dependencies should be satisfiable from the distribution used for the rebuild; if they are not, a recursive process starts, whereby the packages mentioned in the <literal>Build-Depends</literal> field must be backported before the target package can be. Some packages may not need backporting, and can be installed as-is during the build process (a notable example is <emphasis role="pkg">debhelper</emphasis>). Note that the backporting process can quickly become complex if you are not careful. Therefore, backports should be kept to a strict minimum when possible.
nb-NO: Hvis du vet sikkert at disse byggeavhengigheter er for strenge, bør du føle deg fri til å løsne på dem lokalt. Å lese filene som dokumenterer den vanlige måten å bygge programvare på - disse filene blir ofte kalt <filename>INSTALL</filename> - vil hjelpe deg å finne de riktige avhengighetene. Ideelt sett bør alle avhengigheter være imøtekommet fra distribusjonen som brukes til ombygging. Hvis de ikke er det, starter en gjentakingsprosess, der pakkene nevnt i <literal>Build-Depends</literal>-feltet må «backportes» («tilbakeporting») før målet pakken kan bli det. Noen pakker trenger kanskje ikke tilbakeporting, og kan installeres som de er i løpet av byggeprosessen (et kjent eksempel er <emphasis role="pkg">debhelper</emphasis>). Merk at tilbakeportingsprosessen raskt kan bli komplisert hvis du ikke er forsiktig. Derfor bør tilbakeporting holdes på et absolutt minimum der det er mulig.

en: <emphasis>TIP</emphasis> Installing <literal>Build-Depends</literal>
nb-NO: <emphasis>TIPS</emphasis> innstallere <literal>Build-Depends</literal>

en: <command>apt-get</command> allows installing all packages mentioned in the <literal>Build-Depends</literal> fields of a source package available in a distribution mentioned in a <literal>deb-src</literal> line of the <filename>/etc/apt/sources.list</filename> file. This is a simple matter of running the <command>apt-get build-dep <replaceable>package</replaceable></command> command.
nb-NO: <command>apt-get</command> tillater installasjon av alle pakker nevnt i <literal>Build-Depends</literal>-feltene til en kildepakke som er tilgjengelig i en distribusjon nevnt i en <literal>deb-src</literal>-linje i <filename>/etc/apt/sources.list</filename>-filen. Dette er så enkelt som å kjøre kommandoen <command>apt-get build-dep <replaceable>pakke</replaceable></command>.

en: Starting the Rebuild
nb-NO: Å starte gjenoppbyggingen

en: When all the needed changes have been applied to the sources, we can start generating the actual binary package (<filename>.deb</filename> file). The whole process is managed by the <command>dpkg-buildpackage</command> command.
nb-NO: Når alle de nødvendige endringene har blitt brukt på kildene, kan vi starte å generere den aktuelle binære pakkefilen (<filename>.deb</filename>). Hele prosessen er håndtert av <command>dpkg-buildpackage</command>-kommandoen.

en: Rebuilding a package
nb-NO: Å bygge om en pakke

en: The other options used in the above example make sure that neither the source package's <filename>.dsc</filename> (<literal>-us</literal>) nor the produced <filename>.changes</filename> file (<literal>-uc</literal>) get signed with the package builder's cryptographic key after the asuccessful build.
nb-NO: De andre valgene i eksempelet ovenfor sørger for at hverken kildepakkens <filename>.dsc</filename> (<literal>-us</literal>) og ei heller resulterende <filename>.changes</filename>-fil (<literal>-uc</literal>) signeres med pakkebyggerens kryptografiske nøkkel etter at bygget fullføres på riktig vis.

en: <emphasis>TOOL</emphasis> <command>fakeroot</command>
nb-NO: <emphasis>VERKTØY</emphasis> <command>fakeroot</command>

en: <primary>account</primary><secondary>root account</secondary>
nb-NO: <primary>konto</primary><secondary>root-konto</secondary>

en: In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by <emphasis>root</emphasis> in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the <command>fakeroot</command> command. This tool can be used to run a program and give it the impression that it runs as <emphasis>root</emphasis> and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including <emphasis>root</emphasis>. This setup is so convenient that <command>dpkg-buildpackage</command> uses <command>fakeroot</command> by default when building packages.
nb-NO: I hovedsak er prosessen med å bygge pakker en så enkel sak som, i et arkiv, å samle et sett av eksisterende (eller bygde) filer. De fleste filene vil så bli eid av <emphasis>rot</emphasis> i arkivet. Men å bygge hele pakken under denne brukeren skulle tilsi økt risiko. Heldigvis kan dette unngås med <command>fakeroot</command>-kommandoen. Dette verktøyet kan brukes til å kjøre et program, og gi inntrykk av at det kjører som <emphasis>root</emphasis>, og skaper filer med vilkårlig eierskap og rettigheter. Når programmet skaper arkivet som vil bli Debian-pakken, er det lurt å skape et arkiv som inneholder filer merket som tilhørende vilkårlige eiere, inkludert <emphasis>rot</emphasis>. Dette oppsettet er så praktisk at <command>dpkg-buildpackage</command> bruker <command>fakeroot</command> som standard ved pakkebygging.

en: Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running <command>fakeroot <replaceable>program</replaceable></command> (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.
nb-NO: Merk at programmet bare er lurt til å «tro» at det fungerer som en priviligert konto, og prosessen faktisk kjører som om brukeren kjører <command>fakeroot <replaceable>program</replaceable></command> (og filene faktisk er opprettet med den brukerens tillatelser). Ikke på noe tidspunkt får det faktisk rotprivilegier som det kunne misbruke.

en: <emphasis>QUICK LOOK</emphasis> Building packages in <emphasis>chrooted</emphasis> and <emphasis>virtual</emphasis> environments
nb-NO: <emphasis>RASK TITT</emphasis> Bygging av pakker i <emphasis>chrooted</emphasis> og <emphasis>virtuelle</emphasis> omgivelser

en: <primary>virtualization</primary>
nb-NO: <primary>virtualisering</primary>

en: Building your First Package
nb-NO: Å bygge din første pakke

en: Meta-Packages or Fake Packages
nb-NO: Meta-pakker eller falske pakker

en: <primary>package</primary><secondary>meta-package</secondary>
nb-NO: <primary>pakke</primary><secondary>meta-pakke</secondary>

en: <primary>meta-package</primary>
nb-NO: <primary>meta-pakke</primary>

en: Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.
nb-NO: Falske pakker og meta-pakker er like ved at de er tomme skall som bare eksisterer for effektene meta-dataene deres har på pakkehåndteringsstabelen.

en: The purpose of a fake package is to trick <command>dpkg</command> and <command>apt</command> into believing that some package is installed even though it is only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.
nb-NO: Formålet med en falsk pakke er å lure <command>dpkg</command> og <command>apt</command> til å tro at noen pakker er installert, selv om det bare er et tomt skall. Dette tillater tilfredsstilling av avhengigheter i en pakke når den tilsvarende programvaren ble installert utenfor rammen av pakkesystemet. En slik metode fungerer, men bør likevel unngås når det er mulig, ettersom det ikke er noen garanti for at den manuelt installerte programvaren oppfører seg akkurat som den tilsvarende pakken ville ha gjort, og andre pakker som er avhengig av den, ikke vil fungere ordentlig.

en: On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.
nb-NO: På den annen side, en meta-pakke består oftest som en samling av avhengigheter, slik at montering av meta-pakken faktisk vil føre inn et sett av andre pakker i et enkelt trinn.

en: Both these kinds of packages can be created by the <command>equivs-control</command> and <command>equivs-build</command> commands (in the <emphasis role="pkg">equivs</emphasis> package). The <command>equivs-control <replaceable>file</replaceable></command> command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The <literal>Copyright</literal>, <literal>Changelog</literal>, <literal>Readme</literal> and <literal>Extra-Files</literal> fields are not standard fields in Debian packages; they only make sense within the scope of <command>equivs-build</command>, and they will not be kept in the headers of the generated package.
nb-NO: Begge disse pakkesalgene kan lages av kommandoene <command>equivs-control</command> og <command>equivs-build</command> (i <emphasis role="pkg">equivs</emphasis>-pakken). Kommandoene <command>equivs-control <replaceable>filen</replaceable></command> oppretter en Debian-pakke topptekstfil som skal redigeres for å inneholde navnet på den forventede pakken, dens versjonsnummer, navnet på vedlikeholderen, avhengighetene, og beskrivelsen. Andre felt uten en standardverdi er valgfrie, og kan slettes. Feltene <literal>Copyright</literal>, <literal>Changelog</literal>, <literal>Readme</literal> og <literal>Extra-Files</literal> er ikke standard felt i Debian-pakker; de bare gir mening innenfor rammen av <command>equivs-build</command>, og de vil ikke bli beholdt i overskriftene til den genererte pakken.

en: Header file of the <emphasis>libxml-libxml-perl</emphasis> fake package
nb-NO: Topptekstfil for den falske pakken <emphasis>libxml-libxml-perl</emphasis>

en: The next step is to generate the Debian package with the <command>equivs-build <replaceable>file</replaceable></command> command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.
nb-NO: Det neste skrittet er å generere Debian-pakken med kommandoen <command>equivs-build <replaceable>filen</replaceable></command>. Og plutselig er pakken opprettet i den gjeldende katalogen, og kan håndteres som enhver annen Debian-pakke ville blitt.

en: Simple File Archive
nb-NO: Et enkelt filarkiv

en: The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package. <ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />
nb-NO: For å lette utplasseringen av et sett med dokumentasjon på et stort antall maskiner, trenger Falcot Corp-administratorene å lage en Debian-pakke. Administratoren med ansvaret for denne oppgaven leser først «Guide for nye Debian vedlikeholder» («New Maintainer's Guide»), og begynner så å jobbe med sin første pakke. <ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />

en: The first step is creating a <filename>falcot-data-1.0</filename> directory to contain the target source package. The package will logically, be named <literal>falcot-data</literal> and bear the <literal>1.0</literal> version number. The administrator then places the document files in a <filename>data</filename> subdirectory. Then they invoke the <command>dh_make</command> command (from the <emphasis role="pkg">dh-make</emphasis> package) to add files required by the package generation process, which will all be stored in a <filename>debian</filename> subdirectory:
nb-NO: Det første skrittet er å lage en <filename>falcot-data-1.0</filename>-mappe som skal inneholde mål-kildepakken. Pakken vil logisk nok få navnet <literal>falcot-data</literal>, og bære versjonsnummeret <literal>1.0</literal>. Administratoren plasserer så dokumentasjonsfilene i en <filename>data</filename>-undermappe. Så påkaller de <command>dh_make</command>-kommandoen (fra <emphasis role="pkg">dh-make</emphasis>-pakken) for å legge til filene som kreves for pakke-genereringsprosessen - som alle blir lagret i en <filename>debian</filename>-undermappe:

en: The selected type of package (<emphasis>indep</emphasis>) indicates that this source package will generate a single binary package that can be shared across all architectures (<literal>Architecture: all</literal> in <filename>debian/control</filename>). <emphasis>single</emphasis> acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (<literal>Architecture: any</literal>). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.
nb-NO: Den valgte pakketypen (<emphasis>indep</emphasis>) indikerer at denne kildepakken vil generere en enkelt binærpakke som kan deles på tvers av alle arkitekturer (<literal>Architecture: all</literal> i <filename>debian/control</filename>). <emphasis>single</emphasis> er et alternativ, og fører til en enkelt binærpakke som er avhengig av målarkitekturen (<literal>Architecture: any</literal>). I dette tilfellet er valget mer relevant, siden pakken bare inneholder dokumentasjon, og ingen binære programmer, slik at den kan brukes enhver datamaskiner uavhengig av arkitektur.

en: <primary>package</primary><secondary>types</secondary>
nb-NO: <primary>pakke</primary><secondary>typer</secondary>

en: <primary>package</primary><secondary>architecture</secondary>
nb-NO: <primary>pakke</primary><secondary>arkitektur</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Architecture</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Architecture</literal>, hodefelt</secondary>

en: The <emphasis>library</emphasis> type corresponds to a source package leading to several binary packages. It is useful for shared libraries, since they need to follow strict packaging rules.
nb-NO: <emphasis>library</emphasis>-typen svarer til en kildekodepakke som leder til forskjellige binærpakker. Det er nyttig for delte biblioteker, siden de må følge strenge pakkeregler.

en: <emphasis>TIP</emphasis> Maintainer's name and email address
nb-NO: <emphasis>TIPS</emphasis> Vedlikeholders navn og e-post

en: <primary><varname>DEBFULLNAME</varname></primary><see>environment variable</see>
nb-NO: <primary><varname>DEBFULLNAME</varname></primary><see>miljøvariabel</see>

en: <primary>environment variable</primary><secondary><varname>DEBFULLNAME</varname></secondary>
nb-NO: <primary>miljøvariabel</primary><secondary><varname>DEBFULLNAME</varname></secondary>

en: <primary><varname>DEBEMAIL</varname></primary><see>environment variable</see>
nb-NO: <primary><varname>DEBEMAIL</varname></primary><see>miljøvariabel</see>

en: <primary>environment variable</primary><secondary><varname>DEBEMAIL</varname></secondary>
nb-NO: <primary>miljøvariabel</primary><secondary><varname>DEBEMAIL</varname></secondary>

en: <primary><varname>EMAIL</varname></primary><see>environment variable</see>
nb-NO: <primary><varname>EMAIL</varname></primary><see>miljøvariabel</see>

en: <primary>environment variable</primary><secondary><varname>EMAIL</varname></secondary>
nb-NO: <primary>miljøvariabel</primary><secondary><varname>EMAIL</varname></secondary>

en: Most of the programs involved in package maintenance will look for your name and email address in the <varname>DEBFULLNAME</varname> and <varname>DEBEMAIL</varname> or <varname>EMAIL</varname> environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is <command>bash</command>, it is a simple matter of adding the following two lines in your <filename>~/.bashrc</filename> file (you will obviously replace the values with more relevant ones!):
nb-NO: De fleste programmene involvert i pakkevedlikeholdet vil søke etter ditt navn og e-postadresse i <varname>DEBFULLNAME</varname> og <varname>DEBEMAIL</varname>, eller <varname>EMAIL</varname>-miljøvariabler. Ved å definere dem en gang for alle, vil du unngå å måtte sortere dem flere ganger. Hvis ditt vanlige skall er <command>bash</command>, er det bare å legge til følgende to linjer i din <filename>~/.bashrc</filename>-file (du vil ganske sikkert erstatte verdiene med noen mer relevante!):

en: <primary><filename>debian</filename>, directory</primary>
nb-NO: <primary><filename>debian</filename>, mappe</primary>

en: <primary><filename>debian</filename>, directory</primary><secondary><filename>rules</filename></secondary><seealso><filename>rules</filename></seealso>
nb-NO: <primary><filename>debian</filename>, mappe</primary><secondary><filename>rules</filename></secondary><seealso><filename>rules</filename></seealso>

en: <primary><filename>debian</filename>, directory</primary><secondary><filename>control</filename></secondary><seealso><filename>control</filename></seealso>
nb-NO: <primary><filename>debian</filename>, mappe</primary><secondary><filename>control</filename></secondary><seealso><filename>control</filename></seealso>

en: <primary><filename>debian</filename>, directory</primary><secondary><filename>changelog</filename></secondary><seealso><filename>changelog</filename></seealso>
nb-NO: <primary><filename>debian</filename>, mappe</primary><secondary><filename>changelog</filename></secondary><seealso><filename>changelog</filename></seealso>

en: <primary><filename>debian</filename>, directory</primary><secondary><filename>copyright</filename></secondary><seealso><filename>copyright</filename></seealso>
nb-NO: <primary><filename>debian</filename>, mappe</primary><secondary><filename>copyright</filename></secondary><seealso><filename>copyright</filename></seealso>

en: The <filename>copyright</filename> file must contain information about the authors of the documents included in the package, and the related copyright and license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default format used for this file is defined in the <literal>Format</literal> field. <ulink type="block" url="https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/" />
nb-NO: <filename>copyright</filename>-filen må inneholde info om utviklerne av dokumenter som inkluderes i pakken, og relatert opphavsrett og lisens. I vår fall er dette interne dokumenter hvis bruk er begrenset til Falcot Corp-bedriften. Forvalgt format brukt for denne filen er definert i <literal>Format</literal>-feltet. <ulink type="block" url="https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/" />

en: The default <filename>changelog</filename> file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from <literal>UNRELEASED</literal> or <literal>unstable</literal> to the target release name is enough.
nb-NO: Forvalgt <filename>changelog</filename>-fil er vanligvis anvendbar; der man erstatter «opprinnelig utgave» med en mer sirlig forklaring og endring av distribusjonen fra <literal>UNRELEASED</literal> eller <literal>unstable</literal> til målutgivelsen er nok.

en: <primary><filename>control</filename></primary><secondary><literal>Depends</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Depends</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Homepage</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Homepage</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Rules-Requires-Root</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Rules-Requires-Root</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Section</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Section</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Vcs-Browser</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Vcs-Browser</literal>, hodefelt</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Vcs-Git</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Vcs-Git</literal>, hodefelt</secondary>

en: The <filename>control</filename> file
nb-NO: <filename>control</filename>-filen

en: The <filename>changelog</filename> file
nb-NO: <filename>changelog</filename>-filen

en: The <filename>copyright</filename> file
nb-NO: <filename>copyright</filename>-filen

en: <emphasis>BACK TO BASICS</emphasis> <filename>Makefile</filename> file
nb-NO: <emphasis>DET GRUNNLEGGENDE</emphasis> <filename>Makefile</filename>-fil

en: A <filename>Makefile</filename> file is a script used by the <command>make</command> program; it describes rules for how to build a set of files from each other in a tree of dependencies (for instance, a program can be built from a set of source files). The <filename>Makefile</filename> file describes these rules in the following format:
nb-NO: <filename>Makefile</filename>-filen er et skript som brukes av <command>make</command>-programmet: Det beskriver regler for hvordan man skal bygge et sett med filer fra hverandre i et tre med avhengigheter (for eksempel kan et program bygges fra et sett med kildefiler). <filename>Makefile</filename>-filen beskriver disse reglene i det følgende formatet:

en: 
    target: source1 source2 ...
            command1
            command2
nb-NO: 
    mål: kilde1 kilde2 ...
            kommando1
            kommando2

en: Note that the command lines must start with a tab character; also note that when a command line starts with a dash character (<literal>-</literal>), failure of the command does not interrupt the whole process.
nb-NO: Merk at kommandolinjene må starte med et TAB-tegn; Merk også at når en kommandolinje starter med en skråstrek (<literal>-</literal>), avbryter ikke feil i kommandoen hele prosessen.

en: The <filename>rules</filename> file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the <filename>debian/falcot-data/usr/share/falcot-data/</filename> subdirectory, so that installing the generated package will deploy the files under <filename>/usr/share/falcot-data/</filename>. The <filename>rules</filename> file is used as a <filename>Makefile</filename>, with a few standard targets (including <literal>clean</literal> and <literal>binary</literal>, used respectively to clean the source directory and generate the binary package).
nb-NO: Filen <filename>rules</filename> inneholder vanligvis et sett med regler til å sette opp, bygge og installere programvaren i en egen underkatalog (oppkalt etter den genererte binære pakken). Innholdet i denne underkatalogen blir deretter arkivert i Debian-pakken som om det var roten i filsystemet. I vårt tilfelle vil filene bli installert i <filename>debian/falcot-data/usr/share/falcot-data/</filename>-undermappe, slik at å installere den genererte pakken, vil plassere filene under <filename>/usr/share/falcot-data/</filename>. Filen <filename>rules</filename> blir brukt som en <filename>Makefile</filename>, med noen få standard mål (medregnet <literal>clean</literal> og <literal>binary</literal>, respektivt brukt til å rydde opp i kildemappen og generere binærpakken).

en: Although this file is the heart of the process, it increasingly contains only the bare minimum for running a standard set of commands provided by the <command>debhelper</command> tool. Such is the case for files generated by <command>dh_make</command>. To install our files, we simply configure the behavior of the <command>dh_install</command> command by creating the following <filename>debian/falcot-data.install</filename> file:
nb-NO: Selv om denne filen er hjertet av prosessen, inneholder den i økende grad bare et minimum for å kjøre et standard sett med kommandoer gitt av <command>debhelper</command>-verktøyet. Slik er tilfellet for filer generert av <command>dh_make</command>. For å installere våre filer må vi ganske enkelt sette opp atferden til <command>dh_install</command>-kommandoen ved å lage den følgende <filename>debian/falcot-data.install</filename>-filen:

en: At this point, the package can be created. We will, however, add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a <filename>falcot-data.desktop</filename> file and get it installed in <filename>/usr/share/applications</filename> by adding a second line to <filename>debian/falcot-data.install</filename>.
nb-NO: På dette tidspunktet kan pakken opprettes. Vi vil imidlertid legge til et malingstrøk. Siden administratorene ønsker at dokumentasjonen blir lett tilgjengelig fra menyene i grafiske skrivebordsmiljøer, legger vi til en <filename>falcot-data.desktop</filename>-file og får den installert i <filename>/usr/share/applications</filename> ved å legge til en andre linje til <filename>debian/falcot-data.install</filename>.

en: The <filename>falcot-data.desktop</filename> file
nb-NO: Filen <filename>falcot-data.desktop</filename>

en: The updated <filename>debian/falcot-data.install</filename> looks like this:
nb-NO: Den oppdaterte <filename>debian/falcot-data.install</filename> ser slik ut:

en: Our source package is now ready. All that is left to do is to generate the binary package, with the same method we used previously for rebuilding packages: we run the <command>dpkg-buildpackage -us -uc</command> command from within the <filename>falcot-data-1.0</filename> directory.
nb-NO: Vår kildepakke er nå klar. Alt som gjenstår er å generere den binære pakken med den samme metoden vi brukte tidligere for å bygge om pakker: vi kjører <command>dpkg-buildpackage -us -uc</command>-kommandoen fra <filename>falcot-data-1.0</filename>-mappen.

en: Creating a Package Repository for APT
nb-NO: Å lage en pakkebrønn for APT

en: <primary>package</primary><secondary>archive</secondary>
nb-NO: <primary>pakke</primary><secondary>arkiv</secondary>

en: <primary>package</primary><secondary>Debian</secondary><tertiary>archive of</tertiary>
nb-NO: <primary>pakke</primary><secondary>Debian</secondary><tertiary>arkiv</tertiary>

en: Falcot Corp gradually started maintaining a number of Debian packages either locally modified from existing packages or created from scratch to distribute internal data and programs.
nb-NO: Falcot Corp begynte gradvis å vedlikeholde en rekke Debian-pakker, enten lokalt endret fra eksisterende pakker, eller laget fra bunnen av, for å distribuere interne data og programmer.

en: To make deployment easier, they want to integrate these packages in a package archive that can be directly used by APT. For obvious maintenance reasons, they wish to separate internal packages from locally-rebuilt packages. The goal is for the matching entries in a <filename>/etc/apt/sources.list.d/falcot.list</filename> file to be as follows:
nb-NO: For å gjøre utplassering lettere ønsker de å integrere disse pakkene i et pakkearkiv som kan brukes direkte av APT. Av åpenbare vedlikeholdsgrunner ønsker de å skille interne pakker fra lokalt ombygde pakker. Målet for de samsvarende oppføringene i en <filename>/etc/apt/sources.list.d/falcot.list</filename>-fil er som følger:

en: The administrators therefore configure a virtual host on their internal HTTP server, with <filename>/srv/vhosts/packages/</filename> as the root of the associated web space. The management of the archive itself is delegated to the <command>mini-dinstall</command> command (in the similarly-named package). This tool keeps an eye on an <filename>incoming/</filename> directory (in our case, <filename>/srv/vhosts/packages/mini-dinstall/incoming/</filename>) and waits for new packages there; when a package is uploaded, it is installed into a Debian archive at <filename>/srv/vhosts/packages/</filename>. The <command>mini-dinstall</command> command reads the <filename>*.changes</filename> file created when the Debian package is generated. These files contain a list of all other files associated with the version of the package (<filename>*.deb</filename>, <filename>*.dsc</filename>, <filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>, <filename>*.orig.tar.gz</filename>, or their equivalents with other compression tools), and these allow <command>mini-dinstall</command> to know which files to install. <filename>*.changes</filename> files also contain the name of the target distribution (often <literal>unstable</literal>) mentioned in the latest <filename>debian/changelog</filename> entry, and <command>mini-dinstall</command> uses this information to decide where the package should be installed. This is why administrators must always change this field before building a package, and set it to <literal>internal</literal> or <literal>updates</literal>, depending on the target location. <command>mini-dinstall</command> then generates the files required by APT, such as <filename>Packages.gz</filename>.
nb-NO: Administratorene setter derfor opp en virtuell maskin på deres interne HTTP-tjener, med <filename>/srv/vhosts/packages/</filename> som roten til det tilhørende nettområdet. Håndteringen av selve arkivet er delegert til <command>mini-dinstall</command>-kommandoen (i den tilsvarende navngitte pakken). Dette verktøyet holder et øye med en <filename>incoming/</filename>-mappe (i vårt tilfelle, <filename>/srv/vhosts/packages/mini-dinstall/incoming/</filename>), og venter på nye pakker der; når en pakke er lastet opp, blir den installert i et Debian-arkiv på <filename>/srv/vhosts/packages/</filename>. Kommandoen <command>mini-dinstall</command> leser <filename>*.changes</filename>-filen som opprettes når Debian-pakken blir generert. Disse filene inneholder en liste med alle andre filer knyttet til den versjonen av pakken (<filename>*.deb</filename>, <filename>*.dsc</filename>, <filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>, <filename>*.orig.tar.gz</filename>, eller tilsvarende med andre komprimeringsverktøy), og disse åpner for at <command>mini-dinstall</command> får vite hvilke filer som skal installeres. <filename>*.changes</filename>-filer inneholder også navnet på måldistribusjonen (ofte <literal>unstable</literal>) nevnt i den siste <filename>debian/changelog</filename>-inngangen, og <command>mini-dinstall</command> bruker denne informasjonen til å avgjøre hvor pakken skal installeres. Dette er grunnen til at administratorer alltid må endre dette feltet før de bygger en pakke, og setter det til <literal>internal</literal>, eller <literal>updates</literal>, avhengig av måldistribusjonen. <command>mini-dinstall</command> genererer deretter filene som kreves av APT, for eksempel <filename>Packages.gz</filename>.

en: <emphasis>ALTERNATIVE</emphasis> <command>apt-ftparchive</command>, <command>aptly</command>, and <command>reprepro</command>
nb-NO: <emphasis>ALTERNATIV</emphasis> <command>apt-ftparchive</command>, <command>aptly</command>, og <command>reprepro</command>

en: If <command>mini-dinstall</command> seems too complex for your Debian archive needs, you can also use the <command>apt-ftparchive</command> command. This tool scans the contents of a directory and displays (on its standard output) a matching <filename>Packages</filename> file. In the Falcot Corp case, administrators could upload the packages directly into <filename>/srv/vhosts/packages/updates/</filename> or <filename>/srv/vhosts/packages/internal/</filename>, then run the following commands to create the <filename>Packages.gz</filename> files:
nb-NO: Hvis <command>mini-dinstall</command> ser for omfattende ut for dine Debian-arkivbehov, kan du også bruke <command>apt-ftparchive</command>-kommandoen. Dette verktøyet skanner innholdet i en katalog, og viser (i sine standard utdata) en samsvarende <filename>Packages</filename>-fil. I tilfellet Falcot Corp kunne administratorer laste pakkene direkte inn i <filename>/srv/vhosts/packages/updates/</filename>, eller <filename>/srv/vhosts/packages/internal/</filename>, og så kjøre de følgende kommandoer for å lage <filename>Packages.gz</filename>-filene:

en: The <command>apt-ftparchive sources</command> command allows creating <filename>Sources.gz</filename> files in a similar fashion.
nb-NO: Kommandoen <command>apt-ftparchive sources</command> åpner for å lage <filename>Sources.gz</filename>-filer på en lignende måte.

en: <command>reprepro</command> and <command>aptly</command> are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. <command>reprepro</command> stores packages and checksums in a Berkeley DB database file, so no database server is needed. <command>aptly</command> provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.
nb-NO: <command>reprepro</command> and <command>aptly</command> er mer avanserte verktøy tiltenkt samme formål. De kan produsere, håndtere og synkronisere et antall pakkebrønner, speile andre pakkebrønner, og håndplukke pakker fra offisielle pakkebrønner og tilby dem lokalt, opprette signaturer for de genererte pakkeindeksene, og dermed tilby signerte pakkebrønner. <command>reprepro</command> lagrer pakker og sjekksummer i en Berkeley DB-databasefil, slik at ingen databasetjener behøves. <command>aptly</command> tilbyr samme funksjonalitet, men kan også være enklere å håndtere. Beklageligvis er ingen av dem i aktiv utvikling, tross at de har flest funksjoner.

en: <command>reprepro</command> comes with a lot of documentation and examples in <filename>/usr/share/doc/reprepro/</filename>, while <command>aptly</command> has a vast online documentation. <ulink type="block" url="https://www.aptly.info/" />
nb-NO: <command>reprepro</command> har mye dokumentasjon og eksempler i <filename>/usr/share/doc/reprepro/</filename>, mens <command>aptly</command> har rikholdig nettbasert dokumentasjon. <ulink type="block" url="https://www.aptly.info/" />

en: Configuring <command>mini-dinstall</command> requires setting up a <filename>~/.mini-dinstall.conf</filename> file; in the Falcot Corp case, the contents are as follows:
nb-NO: Å sette opp <command>mini-dinstall</command> krever oppsett av en <filename>~/.mini-dinstall.conf</filename>-fil; i Falcot Corp-tilfellet er innholdet som følger:

en: One decision worth noting is the generation of <filename>Release</filename> files for each archive. This can help manage package installation priorities using the <filename>/etc/apt/preferences</filename> configuration file (see <xref linkend="sect.apt.priorities" /> for details).
nb-NO: En avgjørelse verdt å merke seg er generasjonen <filename>Release</filename>-filer for hvert arkiv. Dette kan hjelpe til med å administrere pakkeinstallasjonsprioriteringer med hjelp av <filename>/etc/apt/preferences</filename>-oppsettsfilen (se <xref linkend="sect.apt.priorities" /> for detaljer).

en: <emphasis>SECURITY</emphasis> <command>mini-dinstall</command> and permissions
nb-NO: <emphasis>SIKKERHET</emphasis> <command>mini-dinstall</command> og tillatelser

en: Since <command>mini-dinstall</command> has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the <filename>incoming/</filename> directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and <command>mini-dinstall</command> does not need to do it again. This explains the <literal>verify_sigs = 0</literal> parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the <literal>extra_keyrings</literal> parameter); <command>mini-dinstall</command> will then check the origin of each incoming package by analyzing the signature integrated to the <filename>*.changes</filename> file.
nb-NO: Etter at <command>mini-dinstall</command> er designet for å kjøres som en vanlig bruker, er det ikke nødvendig å kjøre den som rot. Den enkleste måten er å sette opp alt innen brukerkontoen som tilhører administratoren med ansvar for å lage Debian-pakker. Ettersom bare denne administratoren har de nødvendige tillatelsene til å sette filer inn i <filename>incoming/</filename>-katalogen, kan vi utlede at administratoren har autentisert opprinnelsen til hver pakke før utplasseringen, og <command>mini-dinstall</command> trenger ikke å gjøre det igjen. Dette forklarer <literal>verify_sigs = 0</literal>-parameteret (noe som betyr at signaturene ikke behøver å være bekreftet). Men hvis innholdet i pakkene er sensitivt, kan vi snu innstillingen, og velge å godkjenne en ring med nøkler som inneholder offentlige nøkler til personer med lov til å lage pakker (satt opp med <literal>extra_keyrings</literal>-parameter); <command>mini-dinstall</command> vil så sjekke opprinnelsen til hver innkommende pakke ved å analysere signaturen integrert i <filename>*.changes</filename>-filen.

en: Invoking <command>mini-dinstall</command> actually starts a daemon in the background. As long as this daemon runs, it will check for new packages in the <filename>incoming/</filename> directory every half-hour; when a new package arrives, it will be moved to the archive and the appropriate <filename>Packages.gz</filename> and <filename>Sources.gz</filename> files will be regenerated. If running a daemon is a problem, <command>mini-dinstall</command> can also be manually invoked in batch mode (with the <literal>-b</literal> option) every time a package is uploaded into the <filename>incoming/</filename> directory. Other possibilities provided by <command>mini-dinstall</command> are documented in its <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
nb-NO: Å påkalle <command>mini-dinstall</command> starter faktisk en bakgrunnsprosess i bakgrunnen. Så lenge denne bakgrunnsprosessen kjører, vil den se etter nye pakker i <filename>incoming/</filename>-mappen hver halvtime. Når en ny pakke kommer, vil den bli flyttet til arkivet, og riktige <filename>Packages.gz</filename> og <filename>Sources.gz</filename>-filer blir fornyet. Hvis det å kjøre en bakgrunnsprosess er et problem, kan og <command>mini-dinstall</command> påkalles manuelt i rekkefølge (med <literal>-b</literal>-valget) hver gang en pakke blir lastet inn i <filename>incoming/</filename>-mappen. Andre muligheter som ligger i <command>mini-dinstall</command> er dokumentert på sin <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry>-manualside.

en: <emphasis>EXTRA</emphasis> Generating a signed archive
nb-NO: <emphasis>EKSTRA</emphasis> Å generere et signert arkiv

en: The APT suite checks a chain of cryptographic signatures on the packages it handles before installing them, in order to ensure their authenticity (see <xref linkend="sect.package-authentication" />). Private APT archives can then be a problem, since the machines using them will keep displaying warnings about unsigned packages. A diligent administrator will therefore integrate private archives with the secure APT mechanism.
nb-NO: For å sikre autentisiteten kontrollerer APT-pakken en kjede med kryptografiske signaturer for pakkene den håndterer før de installeres (se <xref linkend="sect.package-authentication" />). Private APT-arkiver kan så bli et problem, ettersom maskinene som bruker dem vil holde på med å vise advarsler om usignerte pakker. En flittig administrator vil derfor integrere privatarkiver med den sikre APT-mekanismen.

en: To help with this process, <command>mini-dinstall</command> includes a <literal>release_signscript</literal> configuration option that allows specifying a script to use for generating the signature. A good starting point is the <filename>sign-release.sh</filename> script provided by the <emphasis role="pkg">mini-dinstall</emphasis> package in <filename>/usr/share/doc/mini-dinstall/examples/</filename>; local changes may be relevant.
nb-NO: For å hjelpe til med denne prosessen inkluderer <command>mini-dinstall</command> et <literal>release_signscript</literal>-oppsettsalternativ som tillater å spesifisere et skript som skal brukes til å generere signaturen. Et godt utgangspunkt er <filename>sign-release.sh</filename>-skriptet fra <emphasis role="pkg">mini-dinstall</emphasis>-pakken i <filename>/usr/share/doc/mini-dinstall/examples/</filename>; lokale endringer kan være relevante.

en: Becoming a Package Maintainer
nb-NO: Å bli en pakkevedlikeholder

en: <primary>package</primary><secondary>maintainer</secondary>
nb-NO: <primary>pakke</primary><secondary>vedlikeholder</secondary>

en: <primary>package</primary><secondary>new maintainer</secondary>
nb-NO: <primary>pakke</primary><secondary>typer</secondary>

en: <primary>maintainer</primary><secondary>package maintainer</secondary>
nb-NO: <primary>vedlikeholder</primary><secondary>pakkevedlikeholder</secondary>

en: Learning to Make Packages
nb-NO: Å lære å lage pakker

en: <primary>package</primary><secondary>creation</secondary>
nb-NO: <primary>pakke</primary><secondary>skape</secondary>

en: Rules
nb-NO: Regler

en: <primary>Debian</primary><secondary>Policy</secondary>
nb-NO: <primary>Debian</primary><secondary>Praksis</secondary>

en: <primary><filename>control</filename></primary><secondary><literal>Standards-Version</literal>, header field</secondary>
nb-NO: <primary><filename>control</filename></primary><secondary><literal>Standards-Version</literal>, hodefelt</secondary>

en: A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The <literal>Standards-Version</literal> field in <filename>debian/control</filename> specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy. <ulink type="block" url="https://www.debian.org/doc/debian-policy/" />
nb-NO: En Debian-pakke må være i samsvar med de presise regler utarbeidet i Debians retningslinjer, og hver pakkeutvikler må kjenne til dem. Det er ingen krav om å kjenne dem utenat, men heller å vite at de eksisterer, og referere til dem når et valg presenterer et ikke-trivielt alternativ. Hver Debian-vedlikeholder har gjort feil ved å ikke kjenne til en regel, men det er ikke et stort problem, så lenge feilen blir fikset når en bruker rapporterer den som en feilrapport (som pleier å skje ganske snart, takket være avanserte brukere). <literal>Standards-Version</literal>-feltet i <filename>debian/control</filename> spesifiserer versjonen av Debian-policyen som en pakke samsvarer med. Vedlikeholdere bør overholde den siste versjonen av Debian-policyen. <ulink type="block" url="https://www.debian.org/doc/debian-policy/" />

en: Procedures
nb-NO: Prosedyrer

en: Debian is not a simple collection of individual packages. Everyone's packaging work is part of a collective project; being a Debian developer involves knowing how the Debian project operates as a whole. Every developer will, sooner or later, interact with others. The Debian Developer's Reference (in the <emphasis role="pkg">developers-reference</emphasis> package) summarizes what every developer must know in order to interact as smoothly as possible with the various teams within the project, and to take the best possible advantages of the available resources. This document also enumerates a number of duties a developer is expected to fulfill. <ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />
nb-NO: Debian er ikke en enkel samling av enkeltpakker. Alles pakkearbeid er en del av et kollektivt prosjekt; å være en Debian-utvikler innebærer å vite hvordan Debian-prosjektet fungerer som en helhet. Hver utbygger vil, før eller senere, samhandle med andre. Debians utviklerreferanse (Debian Developer's Reference) (i <emphasis role="pkg">developers-reference</emphasis>-package) oppsummerer hva alle utviklere må vite for å samhandle så smidig som mulig med de ulike teamene i prosjektet, og for å få mest mulig ut av de tilgjengelige ressursene. Dette dokumentet oppsummerer også en rekke oppgaver en utvikler forventes å oppfylle. <ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />

en: Tools
nb-NO: Verktøy

en: Many tools help package maintainers in their work. This section describes them quickly, but does not give the full details, since they all have comprehensive documentation of their own.
nb-NO: Mange verktøy hjelper pakkevedlikeholdere med deres arbeid. Denne seksjonen gir en rask gjennomgang, uten alle detaljene, ettersom verktøyene har sin egen omfattende dokumentasjon.

en: <primary>package</primary><secondary>tools</secondary>
nb-NO: <primary>pakke</primary><secondary>verktøy</secondary>

en: The <emphasis role="pkg">devscripts</emphasis> package contains many programs helping with a wide array of a Debian developer's job:
nb-NO: Pakken <emphasis role="pkg">devscripts</emphasis> inneholder mange programmer som hjelper til på et stort område i Debian-utviklerens jobb:

en: <command>debuild</command> allows generating a package (with <command>dpkg-buildpackage</command>) and running <command>lintian</command> to check its compliance with the Debian policy afterwards.
nb-NO: <command>debuild</command> tillater å generere en pakke (med <command>dpkg-buildpackage</command>), og kjøre <command>lintian</command> for så å sjekke overensstemmelsen med Debians retningslinjer.

en: <command>debclean</command> cleans a source package after a binary package has been generated.
nb-NO: <command>debclean</command> renser en kildepakke etter at en binærpakke har blitt generert.

en: <command>dch</command> allows quick and easy editing of a <filename>debian/changelog</filename> file in a source package.
nb-NO: <command>dch</command> tillater en rask og enkel redigering av en <filename>debian/changelog</filename>-fil i en kildepakke.

en: <command>uscan</command> checks whether a new version of a software has been released by the upstream author; this requires a <filename>debian/watch</filename> file with a description of the location of such releases.
nb-NO: <command>uscan</command> sjekker om en ny programvareversjon er utgitt av oppstrømsforfatteren; dette krever en <filename>debian/watch</filename>-fil med beskrivelse av plasseringen av slike utgivelser.

en: <primary><filename>debian</filename>, directory</primary><secondary><filename>watch</filename></secondary>
nb-NO: <primary><filename>debian</filename>, mappe</primary><secondary><filename>watch</filename></secondary>

en: <command>debi</command> allows installing (with <command>dpkg -i</command>) the Debian package that was just generated without the need to type its full name and path.
nb-NO: <command>debi</command> tillater installering (med <command>dpkg -i</command>) av Debian-pakken som nettopp ble generert, uten å måtte skrive inn dens fulle navn og sti.

en: In a similar fashion, <command>debc</command> allows scanning the contents of the recently-generated package (with <command>dpkg -c</command>), without needing to type its full name and path.
nb-NO: På lignende måte tillater <command>debc</command> skanning av innholdet i den nylig generert pakken (med <command>dpkg -c</command>), uten å måtte skrive inn dens fulle navn og sti.

en: <command>bts</command> controls the bug tracking system from the command line; this program automatically generates the appropriate emails. <ulink type="block" url="https://www.debian.org/Bugs/server-refcard" />
nb-NO: <command>bts</command> styrer feilrapporteringssystemet fra kommandolinjen; dette programmet genererer automatisk de riktige e-postene. <ulink type="block" url="https://www.debian.org/Bugs/server-refcard" />

en: <command>debrelease</command> uploads a recently-generated package to a remote server, without needing to type the full name and path of the related <filename>.changes</filename> file.
nb-NO: <command>debrelease</command> laster opp en nylig generert pakke til en ekstern tjener, uten å måtte skrive hele navnet og banen til den relaterte <filename>.changes</filename>-filen.

en: <command>debsign</command> signs the <filename>*.dsc</filename> and <filename>*.changes</filename> files.
nb-NO: <command>debsign</command> signerer <filename>*.dsc</filename> og <filename>*.changes</filename>-filene.

en: <command>uupdate</command> automates the creation of a new revision of a package when a new upstream version has been released.
nb-NO: <command>uupdate</command> automatiserer opprettelsen av ny revisjon av en pakke når en ny oppstrømsversjon er utgitt.

en: All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: <filename>~/.devscripts</filename>.
nb-NO: Alle de nevnte kommandoene er dokumentert på respektive manualsider. De kan videre settes opp per bruker i én fil: <filename>~/.devscripts</filename>.

en: <emphasis role="pkg">debhelper</emphasis> and <emphasis role="pkg">dh-make</emphasis>
nb-NO: <emphasis role="pkg">debhelper</emphasis> og <emphasis role="pkg">dh-make</emphasis>

en: The <command>dh_make</command> script (in the <emphasis>dh-make</emphasis> package) creates files required for generating a Debian package in a directory initially containing the sources for a piece of software. As can be guessed from the name of the program, the generated files use debhelper by default.
nb-NO: Skriptet <command>dh_make</command> (i <emphasis>dh-make</emphasis>-pakken) lager filer som kreves for å generere en Debian-pakke i en katalog som i utgangspunktet inneholder kildene for et stykke programvare. Som det kan gjettes fra navnet på programmet, bruker de genererte filene debhelper som standard.

en: This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.
nb-NO: Dette verktøyet er et av de viktigste: Det er Debian-pakkesjekkeren. Den bygger på et stort utvalg av tester opprettet fra Debians retningslinjer, og oppdager raskt og automatisk mange feil som deretter kan rettes før pakkene utgis.

en: This tool is only a helper, and it sometimes gets it wrong (for instance, since the Debian policy changes over time, <command>lintian</command> is sometimes outdated). It is also not exhaustive: not getting any Lintian error should not be interpreted as a proof that the package is perfect; at most, it avoids the most common errors.
nb-NO: Dette verktøyet er bare en hjelper, og noen ganger gjør den feil (for eksempel, siden Debians retningslinjer endrer seg over tid, blir <command>lintian</command> noen ganger utdatert). Det er heller ikke uttømmende: Selv om du ikke får noen Lintian-feilmelding, bør dette ikke tolkes som et bevis på at pakken er perfekt; i beste fall unngås de vanligste feilene.

en: This is another important tool: it automates the installation, upgrade, removal and purge of a package (in an isolated environment), and checks that none of these operations leads to an error. It can help in detecting missing dependencies, and it also detects when files are incorrectly left over after the package got purged.
nb-NO: Dette er et annet viktig redskap: Det automatiserer installasjonen, oppgraderer, fjerner og renser en pakke (i et isolert miljø), og kontrollerer at ingen av disse operasjonene fører til feil. Det kan hjelpe til med å avdekke manglende avhengigheter, og det oppdager også når filer feilaktig er til overs etter at pakken er renset.

en: <primary>package</primary><secondary>tests</secondary>
nb-NO: <primary>pakke</primary><secondary>tester</secondary>

en: <command>reprotest</command> builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then <command>diffoscope</command> (if unavailable, <command>diff</command>) is used to display them in detail for later analysis.
nb-NO: <command> reprotest</command> bygger samme kildekode to ganger i forskjellige miljøer, og kontrollerer deretter binærfilene som produseres av hver oppbygning for forskjeller. Hvis noen blir funnet, brukes <command>diffoskop</command> (hvis det ikke er tilgjengelig, <command>diff</command>) for å vise dem i detalj for senere analyse.

en: <command>dupload</command> and <command>dput</command>
nb-NO: <command>dupload</command> og <command>dput</command>

en: <emphasis role="pkg">git-buildpackage</emphasis> and <emphasis role="pkg">dgit</emphasis>
nb-NO: <emphasis role="pkg">git-buildpackage</emphasis> og <emphasis role="pkg">dgit</emphasis>

en: The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into <emphasis>Git</emphasis> (<xref linkend="sidebar.git" />) onto a Gitlab instance called <literal>salsa.debian.org</literal>. <ulink type="block" url="https://salsa.debian.org/" />
nb-NO: Prosjektet har brukt forskjellige versjonkontrollsystemer i årenes løp for å lagre pakkingstiltak, eller pakke-kildekode, eller for å tillate samarbeid om pakkevedlikehold. For å forene systemene og tiltakene ble det i 2017 besluttet å flytte (nesten) alle pakkekilder inn i <emphasis>Git</emphasis> (<xref linkend="sidebar.git" />) til en GitLab-instans som heter	 <literal>salsa.debian.org</literal>. <ulink type="block" url="https://salsa.debian.org/" />

en: To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.
nb-NO: For å gjøre pakking enklere ved bruk av Git for Debian-utviklerne har det blitt utviklet noen verktøy. Disse tillater ikke bare lagring av pakkingsfiler i Git, men også å bruke Git-kodelager (og historikken deres) til programvareprosjekter, legge til feilfikser for pakkekilder i Git-historikken, vedlikeholde versjoner per distribusjon, osv.

en: One of the most famous packages is <emphasis role="pkg">git-buildpackage</emphasis>. An alternative is <emphasis role="pkg">dgit</emphasis>. Of course it is still possible to use neither of those.
nb-NO: En av de mest kjente pakkene er <emphasis role="pkg">git-buildpackage</emphasis>. Et alternativ er <emphasis role="pkg">dgit</emphasis>. Selvfølgelig er det fremdeles mulig å ikke bruke noen av dem.

en: Below is an example for a <filename>~/.gbp.conf</filename> configuration file
nb-NO: Nedenfor finner du et eksempel for <filename>~/.gbp.conf</filename>-oppsettsfilen

en: Building the package is then as easy as running <command>gbp buildpackage</command> in the Git tree. It will start a package build in a Debian <emphasis role="distribution">Bullseye</emphasis> chroot using <command>sbuild</command>. When the build succeeds, the created files are checked running the <command>autopkgtest</command>-testsuite (if defined). All the various options are explained in <citerefentry><refentrytitle>gbp.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> and <filename>/etc/git-buildpackage/gbp.conf</filename>.
nb-NO: Bygging av pakken kan så gjøres ved å kjøre <command>gbp buildpackage</command> i Git-treet. Det starter bygging av en pakke i en Debian <emphasis role="distribution">Bullseye</emphasis>-chroot ved bruk av <command>sbuild</command>. Når bygget fullføres på riktig vis vil de opprettede filene bli sjekket med utvalget av <command>autopkgtest</command>-programmer (hvis definert). Alle de forskjellige alternativene er forklart i <citerefentry><refentrytitle>gbp.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> og <filename>/etc/git-buildpackage/gbp.conf</filename>.

en: All the tools mentioned so far have been included in the continuous integration (CI) process in the <literal>salsa.debian.org</literal> instance as well: <ulink type="block" url="https://salsa.debian.org/salsa-ci-team/pipeline" />
nb-NO: Alle verktøyene som har blitt nevnt så langt er inkludert i den kontinuerlige integrasjonsprosessen (CI) på <literal>salsa.debian.org</literal>-instansen også: <ulink type="block" url="https://salsa.debian.org/salsa-ci-team/pipeline" />

en: Acceptance Process
nb-NO: Aksepteringsprosess

en: <primary>Debian</primary><secondary>Developer</secondary>
nb-NO: <primary>Debian</primary><secondary>utvikler</secondary>

en: Becoming a “Debian developer” is not a simple administrative matter. The process comprises several steps, and is as much an initiation as it is a selection process. In any case, it is formalized and well-documented, so anyone can track their progression on the website dedicated to the new member process. <ulink type="block" url="https://nm.debian.org/" />
nb-NO: Å bli en «Debian-utvikler» er ikke en enkel administrativ sak. Fremgangsmåten omfatter flere trinn, og er like mye en igangsetting som det er utvelgelsesprosess. I alle fall er det formalisert og godt dokumentert, slik at alle kan spore sin progresjon på nettsiden dedikert til prosessen for det nye medlemmet. <ulink type="block" url="https://nm.debian.org/" />

en: <emphasis>EXTRA</emphasis> Lightweight process for “Debian Maintainers”
nb-NO: <emphasis>EKSTRA</emphasis> Lettvektsprosessen for «Debian vedlikeholdere»

en: “Debian Maintainer” is another status that gives less privileges than “Debian developer” but whose associated process is quicker. With this status, the contributors can maintain their own packages only. A Debian developer only needs to perform a check on an initial upload, and issue a statement to the effect that they trust the prospective maintainer with the ability to maintain the package on their own.
nb-NO: «Debian-vedlikeholder» er en annen status som gir færre privilegier enn «Debian-utvikler», men tilknytningsprosessen går raskere. Med denne statusen kan bidragsyterne bare vedlikeholde sine egne pakker. En Debian-utvikler trenger bare å utføre en sjekk på en første opplasting, og avgi en uttalelse om at de stoler på den potensielle vedlikeholderens evne til å vedlikeholde pakken på egen hånd.

en: Prerequisites
nb-NO: Forutsetninger

en: All candidates are expected to have at least a working knowledge of the English language. This is required at all levels: for the initial communications with the examiner, of course, but also later, since English is the preferred language for most of the documentation; also, package users will be communicating in English when reporting bugs, and they will expect replies in English.
nb-NO: Alle kandidater forventes å ha i det minste arbeidskunnskap om det engelske språket. Dette er nødvendig på alle nivåer: for den første kommunikasjon med den som gjennomgår, selvfølgelig, men også senere, siden engelsk er det foretrukne språket for det meste av dokumentasjonen. I tillegg vil pakkebrukerne kommunisere på engelsk ved innrapportering av feil, og de vil forvente svar på engelsk.

en: The other prerequisite deals with motivation. Becoming a Debian developer is a process that only makes sense if the candidate knows that their interest in Debian will last for many months. The acceptance process itself may last for several months, and Debian needs developers for the long haul; each package needs permanent maintenance, and not just an initial upload.
nb-NO: Den andre forutsetningen omhandler motivasjon. Å bli en Debian-utvikler er en prosess som bare gir mening dersom kandidaten vet at interessen for Debian vil vare i mange måneder. Aksepteringsprosessen kan i seg selv vare flere måneder, og Debian trenger langtidsutviklere. Hver pakke trenger permanent vedlikehold, og ikke bare en første opplasting.

en: Registration
nb-NO: Registrering

en: <primary>package</primary><secondary>sponsor</secondary>
nb-NO: <primary>pakke</primary><secondary>sponsor</secondary>

en: The first (real) step consists in finding a sponsor or advocate; this means an official developer willing to state that they believe that accepting <emphasis>X</emphasis> would be a good thing for Debian. This usually implies that the candidate has already been active within the community, and that their work has been appreciated. If the candidate is shy and their work is not publicly touted, they can try to convince a Debian developer to advocate them by showing their work in a private way.
nb-NO: Det første (virkelige) trinnet består i å finne en sponsor eller talsperson. Det betyr en offisiell utvikler som er villig til å si at de tror at å akseptere, <emphasis>X</emphasis> vil bli en god ting for Debian. Dette innebærer vanligvis at kandidaten allerede har vært aktiv i fellesskapet, og at arbeidet har blitt verdsatt. Dersom kandidaten er sjenert, og arbeidet ikke er offentlig kjent, kan de prøve å overbevise en Debian-utvikler til å argumentere for dem ved å vise deres arbeid i fortrolighet.

en: <primary>key pair</primary>
nb-NO: <primary>nøkkelpar</primary>

en: At the same time, the candidate must generate a public/private RSA key pair with GnuPG, which should be signed by at least two official Debian developers. The signature authenticates the name on the key. Effectively, during a key signing party, each participant must show an official identification (usually an ID card or passport) together with their key identifiers. This step confirms the link between the human and the keys. This signature thus requires meeting in real life. If you have not yet met any Debian developers in a public free software conference, you can explicitly seek developers living nearby using the list on the following webpage as a starting point. <ulink type="block" url="https://wiki.debian.org/Keysigning" />
nb-NO: Samtidig må kandidaten generere et offentlig/privat RSA-nøkkelpar med GnuPG, som skal være underskrevet av minst to offisielle Debian-utviklere. Signaturen godkjenner navnet på nøkkelen. Under et nøkkelsigneringsselskap må faktisk hver deltaker vise en offisiell identifikasjon (vanligvis et ID-kort eller pass) sammen med sine nøkkelidentifiseringer. Dette trinnet bekrefter sammenhengen mellom mennesker og nøklene. Denne signaturen krever dermed at en møtes i det virkelige liv. Hvis du ennå ikke har møtt noen Debian-utviklere på en offentlig fri programvarekonferanse, kan du eksplisitt søke utviklere som bor i nærheten ved hjelp av en liste på følgende nettside som utgangspunkt. <ulink type="block" url="https://wiki.debian.org/Keysigning" />

en: Once the registration on <literal>nm.debian.org</literal> has been validated by the advocate, an <emphasis>Application Manager</emphasis> is assigned to the candidate. The application manager will then drive the process through multiple pre-defined steps and checks.
nb-NO: Så snart registeringen på <literal>nm.debian.org</literal> er blitt validert av en talsperson, blir en <emphasis>programleder (Application Manager)</emphasis> tildelt kandidaten. Søknadsbehandleren vil så kjøre prosessen gjennom flere forhåndsdefinerte trinn og sjekker.

en: The first verification is an identity check. If you already have a key signed by two Debian developers, this step is easy; otherwise, the application manager will try and guide you in your search for Debian developers close by to organize a meet-up and a key signing.
nb-NO: Den første bekreftelsen er en identitetssjekk. Hvis du allerede har en nøkkel signert av to Debian-utviklere, er dette trinnet lett; ellers vil søknadsbehandleren prøve å veilede deg i ditt søk etter Debian-utviklere i nærheten, for å organisere et møte og en nøkkelsignering.

en: Accepting the Principles
nb-NO: Å akseptere prinsippene

en: These administrative formalities are followed by philosophical considerations. The point is to make sure that the candidate understands and accepts the social contract and the principles behind Free Software. Joining Debian is only possible if one shares the values that unite the current developers, as expressed in the founding texts (and summarized in <xref linkend="the-debian-project" />).
nb-NO: Disse administrative formaliteter følges ut fra filosofiske betraktninger. Poenget er å sørge for at kandidaten forstår og aksepterer den sosiale kontrakten og prinsippene bak fri programvare. Å bli med i Debian er bare mulig hvis man deler de verdier som forener dagens utviklere, som uttrykt i de grunnleggende tekster (og oppsummert i <xref linkend="the-debian-project" />).

en: In addition, each candidate wishing to join the Debian ranks is expected to know the workings of the project, and how to interact appropriately to solve the problems they will doubtless encounter as time passes. All of this information is generally documented in manuals targeting the new maintainers, and in the Debian developer's reference. An attentive reading of this document should be enough to answer the examiner's questions. If the answers are not satisfactory, the candidate will be informed. They will then have to read (again) the relevant documentation before trying again. In the cases where the existing documentation does not contain the appropriate answer for the question, the candidate can usually reach an answer with some practical experience within Debian, or potentially by discussing with other Debian developers. This mechanism ensures that candidates get involved somewhat in Debian before becoming a full part of it. It is a deliberate policy, by which candidates who eventually join the project are integrated as another piece of an infinitely extensible jigsaw puzzle.
nb-NO: I tillegg skal hver kandidat som ønsker å bli med i Debians rekker forventes å kjenne arbeidet i prosjektet, og hvordan de skal samhandle på riktig måte for å løse de problemene de vil utvilsomt vil møte under tiden. All denne informasjonen er vanligvis dokumentert i manualer rettet mot de nye vedlikeholderne, og i Debian-utviklerreferanse. En oppmerksom lesing av dette dokumentet bør være nok til å svare på eksaminators spørsmål. Hvis svarene ikke er tilfredsstillende, vil kandidaten bli informert. De vil da måtte lese (igjen) den relevante dokumentasjonen før de prøver igjen. I de tilfeller hvor den eksisterende dokumentasjonen ikke inneholder riktig svar på spørsmålet, kan kandidaten vanligvis komme med et svar fra litt praktisk erfaring innen Debian, eller potensielt ved å diskutere med andre Debian-utviklere. Denne mekanismen sikrer at kandidatene blir noe involvert i Debian, før de blir en full del av det. Dette er en bevisst politikk, der kandidatene som til slutt blir med i prosjektet, er integrert som en del av et uendelig utvidbart puslespill.

en: This step is usually known as the <emphasis>Philosophy &amp; Procedures</emphasis> (P&amp;P for short) in the lingo of the developers involved in the new member process.
nb-NO: Dette trinnet er vanligvis kjent som <emphasis>Filosofi &amp; Prosedyrer</emphasis> (P&amp; P i kortform) i språket til utviklerne som er involvert i nye medlemmer-prosessen.

en: <primary><emphasis>Philosophy &amp; Procedures</emphasis></primary>
nb-NO: <primary><emphasis>Filosofi &amp; Prosedyrer</emphasis></primary>

en: Checking Skills
nb-NO: Å sjekke ferdigheter

en: Each application to become an official Debian developer must be justified. Becoming a project member requires showing that this status is legitimate, and that it facilitates the candidate's job in helping Debian. The most common justification is that being granted Debian developer status eases maintenance of a Debian package, but it is not the only one. Some developers join the project to contribute to porting to a specific architecture, others want to improve documentation, and so on.
nb-NO: Hver søknad om å bli en offisiell Debian-utvikler må begrunnes. Å bli en prosjektdeltaker krever at en viser at denne statusen er legitim, og at den letter kandidatens jobb med å hjelpe Debian. Den vanligste begrunnelsen er at å ha fått Debian-utviklerstatus, letter vedlikehold av en Debian-pakke, men det er ikke den eneste. Noen utviklere deltar i prosjektet for å bidra til portering til en bestemt arkitektur, andre ønsker å forbedre dokumentasjon, og så videre.

en: This step represents the opportunity for the candidate to state what they intend to do within the Debian project and to show what they have already done towards that end. Debian is a pragmatic project and saying something is not enough, if the actions do not match what is announced. Generally, when the intended role within the project is related to package maintenance, a first version of the prospective package will have to be validated technically and uploaded to the Debian servers by a sponsor among the existing Debian developers.
nb-NO: Dette trinnet representerer muligheten for kandidaten til å si ifra om hva de har tenkt å gjøre i Debian-prosjektet, og for å vise hva de allerede har gjort for dette formålet. Debian er et pragmatisk prosjekt, og å si noe er ikke nok hvis handlinger ikke samsvarer med hva som er annonsert. Vanligvis, når den tiltenkte rolle i prosjektet er knyttet til pakkevedlikehold, må en første versjon av den potensielle pakken være godkjent teknisk, og lastet opp til Debian-tjenere med en sponsor blant de eksisterende Debian-utviklerne.

en: <emphasis>COMMUNITY</emphasis> Sponsoring
nb-NO: <emphasis>FELLESSKAP</emphasis> Sponsing

en: <primary>sponsoring</primary>
nb-NO: <primary>sponsing</primary>

en: <primary>Debian</primary><secondary>New Member</secondary>
nb-NO: <primary>Debian</primary><secondary>Nytt medlem</secondary>

en: Debian developers can “sponsor” packages prepared by someone else, meaning that they publish them in the official Debian repositories after having performed a careful review. This mechanism enables external persons, who have not yet gone through the new member process, to contribute occasionally to the project. At the same time, it ensures that all packages included in Debian have always been checked by an official member.
nb-NO: Debian-utviklerne kan være «sponsor» for pakker utarbeidet av en annen, noe som betyr at de publiserer dem i de offisielle Debian-kildebrønner etter å ha utført en nøye gjennomgang. Denne mekanismen gjør at eksterne personer, som ennå ikke har gått gjennom prosessen for nye medlemmer, fra tid til annen kan bidra til prosjektet. Samtidig sikrer det at alle pakker som er inkludert i Debian alltid har blitt sjekket av et offisielt medlem.

en: This step is known as the <emphasis>Tasks &amp; Skills</emphasis> step (T&amp;S for short) in the examiners' jargon.
nb-NO: Dette skrittet er kjent som <emphasis>Oppgaver &amp; Ferdigheter</emphasis> trinnet (forkortet til: T&amp;S) i eksaminators språkbruk.

en: <primary><emphasis>Tasks &amp; Skills</emphasis></primary>
nb-NO: <primary><emphasis>Oppgaver &amp; Ferdigheter</emphasis></primary>

en: Final Approval
nb-NO: Endelig godkjenning

en: <primary>Debian</primary><secondary>Account Managers</secondary><seealso>DAM</seealso>
nb-NO: <primary>Debian</primary><secondary>kontoadministratorer</secondary><seealso>DAM</seealso>

en: At the very last step, the whole process is reviewed by a DAM (<emphasis>Debian Account Manager</emphasis>). The DAM will review all the information about the candidate that the examiner collected, and makes the decision on whether or not to create an account on the Debian servers. In cases where extra information is required, the account creation may be delayed. Refusals are rather rare if the examiner does a good job of following the process, but they sometimes happen. They are never permanent, and the candidate is free to try again at a later time.
nb-NO: I det aller siste trinnet blir hele prosessen gjennomgått av en DAM (<emphasis>Debians kontoadministratorer</emphasis>). DAM vil gjennomgå all informasjon om kandidaten som sensor har samlet inn, og gjør vedtak hvorvidt det skal opprettes en konto på Debian-tjenerne. I tilfeller der ekstra informasjon er nødvendig, kan det å opprette en konto bli forsinket. Avslag er ganske sjeldne hvis eksaminator gjør en god jobb med å følge prosessen, men kan skje noen ganger. De er aldri permanente, og kandidaten står fritt til å prøve igjen på et senere tidspunkt.

en: The DAM's decision is authoritative and (almost) without appeal, which explains why the people in that seat have often been criticized in the past.
nb-NO: DAMs avgjørelse er autoritativ og (nesten) uten ankemuligheter, noe som forklarer hvorfor folk i denne posisjonen ofte har blitt kritisert i det siste.
