Motu
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Anmerkung: Viele der aufgeführten Links stimmen nicht mehr.
Interview geführt mit Daniel Holbach zum Thema Motu
Am 05.06.2005 haben wir uns gegen 19 Uhr im #ubuntuusers-motu Channel mit Daniel Holbach, einem der zwei Leiter des Motuteams, getroffen. Es sollte eine Art Interview zum Thema Motu werden, um daraus eine Infoseite im Wiki zu erstellen. Einen Einstieg geben und Kontakte ermöglichen. Unser Ziel ist es nicht die Paketierung darin abzuhandeln, weil das Thema zu umfassend ist. Es soll eher eine stichpunktartige Abhandlung werden, worauf es ankommt und mit passenden Links.
Motto: "Was macht ihr?", "Wie macht ihrs?", "Wie kann ich mitmachen?", ...? Wie wird man motu? Wie packe ich ein Paket? Wie muss ein Paket aufgebaut sein?
Eins war allen von Anfang an klar: Wer Paketiert muss englisch lesen und wird die offizielle Dokumentation lesen müssen. Dies wurde auch gleich durch Daniel Holbach noch einmal bestätigt. Im englischen Wiki gibt es schon einen Motubereich, doch leider haben schon einige gemeint, dass das Ganze noch etwas unübersichtlich scheint und wir wollten die Quintessenz aus erster Hand erfahren.
Gleich am Anfang meint Daniel Holbach hierzu:
Nur hatte ich das Gefühl, dass ein straffer Text von jemand, der nicht "drin steckt" gut ist und Paketierung etwas ist, was man über Wochen lernt.
Was bedeutet Motu eigentlich?¶
Ausgeschrieben bedeutet Motu Master of the Universe. Dieser führt ein Team von freiwilligen Paketbetreuern an, die das Privileg haben, Pakete in dem universe Repository hochzuloaden und zu pflegen.
Universe ist einer der Bereiche im Ubuntu-Paketverwaltungssystems. Die Bereiche enthalten jeweils einen Teil der verfügbaren Pakete und unterscheiden sich im Grad der Unterstützung durch die Entwickler von Ubuntu.
Die universe-Sektion umfasst ein breites Spektrum an freier Software, die unabhängig von ihrer Lizenz nicht vom Ubuntu-Team unterstützt wird. Damit hat der Benutzer die Möglichkeit, solche Programme des Ubuntu-Paketverwaltungssystems zu installieren, aber sie sind getrennt von unterstützten Paketen wie in main und restricted.
Unter Hoary wird zur Zeit für die Qualität und Konsistenz von circa 15.000 gesorgt. Wer Interesse an einer solchen Tätigkeit hat, muss einen Prozess der Akkreditierung durchlaufen. Man muss nicht direkt mit der Pflege eines Paketes anfangen. Es gibt auch die Möglichkeit sich als Helferlein zu betätigen.
"Was machen MOTUs?"¶
Die MOTUs kümmern sich um universe und multiverse. Das kommt vielleicht selten rüber, aber das tun wir tatsächlich. Wir fixen, machen die großen Umstellungen und bringen manchmal auch neue Pakete rein. http://wiki.ubuntu.com/UniverseCandidates 🇬🇧 sind die von Usern gewünschten Pakete.
Auf http://www.ubuntulinux.org/wiki/UniverseNewPackages 🇬🇧 stehen die Pakete dann, wenn sie fertig sind.
Wir haben einen Prozess aufgesetzt, der verlangt, dass ein neues Paket von mindestens 3 Maintainern/MOTUs angeschaut wird; https://wiki.ubuntu.com/MOTU/Packages/Reviewing 🇬🇧. So haben wir eine Qualitätssicherung.
https://wiki.ubuntu.com/BreezyToolchainTransition 🇬🇧 ist z.B. ein RIESENPROJEKT, wo die Motus eingesprungen sind. Die Kommunikation läuft weitgehend über #ubuntu-motu auf irc.freenode.net. Die Leute tragen sich in Listen ein und kommunizieren im Channel oder per Mail untereinander. So wird vermieden, dass zwei Leute gleichzeitig an einem Problem arbeiten.
Ansonsten haben wir uns jetzt https://launchpad.ubuntu.com/malone 🇬🇧 zugewandt, dem next generation bugtracking tool für das wir "Stresstester" sind 😉 Launchpad ist eine eigene Entwicklung von Canonical und wird ein Entwicklungstool sein, was Distributionen, Bugs, Source, Übersetzungen, ... handeln kann.
http://wiki.ubuntu.com/MOTUTodo 🇬🇧 sollte im Allgemeinen alle großen Baustellen auflisten.
Weitere Fakten?¶
Unsere Gruppe ist im Moment nur 20+x groß. Weil unser Team noch sehr klein ist/war, waren wir hauptsächlich mit den großen Umstellungen beschäftigt, aber in Zukunft planen wir Teams, die eigene Ideen einbringen können. Da ist noch viel Pioniersluft. MOTUTeams ist z.b. erst der Anfang.
Was ist für den Fall geplant dass die Gruppe einmal wirklich viel größer wird (und es Probleme gibt)?
Wir haben das CommunityCouncil und das TechnicalBoard, hier werden Probleme diskutiert und hoffentlich Lösungen gefunden.
Gibt es da ein internes Entwicklungsteam, oder wird da einer zum Progammieren angestellt?
Es gibt Angestellte von Canonical, aber es wurden auch Ziele als bounties(= Prämien) gesteckt.
Wie funktioniert das Ganze nun konkret?¶
Wir bekommen alle Pakete über einen wahnsinnig ausgetüftelten Prozess von Debian. Sollte also ein Paket in Debian neu sein (ganz neu oder eine neue Version) bekommen wir das Paket - wenn wir nicht in einem der Freezes sind - ebenfalls von Debian.
Hierzu eine Erläuterung durch Reinhard Tartler (siretart):
Mit dem wahnsinnig ausgetüftelte System meint Daniel die debian buildd infrastruktur http://buildd.debian.org/ 🇬🇧 Die ganze Infrastruktur, die da betrieben wird, ist in der Tat alles andere als trivial, und auch sehr schwer in wenigen Worten zu fassen. Eine ganz grobe Formulierung würde so lauten: Man lädt ein Source Paket ins Incoming Verzeichnis hoch, und die Infrastuktur kümmert sich dann darum, dass das Source Paket auf den Build Maschinen gebaut wird. Die dadurch erzeugten Binärpakete werden dann auf den Ftpmaster installiert und an das Mirrornetzwerk weitergegeben. Zum Verständnins: Ubuntu hat ein eigenes Buildd Netzwerk, betrieben von der gleichen Software wie sie Debian auch tut: dak, buildd, sbuild und wanna-build (so heißen die dabei beteiligten Softwarekomponenten). In das System eingespeist werden wie bei Debian auch Pakete, die ubuntu Entwickler verpackt haben. (ein kleiner Unterschied ist, dass Ubuntu Pakete nur in Sourceform aufnimmt. Debian nimmt auch binärpakete an) Weitere Unterschiede? Ein großer Kritikpunkt der Debianer an uns ist, dass alle und damit keiner für konkrete Pakete in universe verantwortlich sind. Wir sehen das (naturgemäß 😉 ein wenig anders: Bei uns darf grundsätzlich jeder jedes Paket anfassen. Wie ist der Zusammenhang zwischen den Debian Maintainer und den an Ubuntu gelieferten Sourcecode? Bleiben die Maintainer für die Pakete verantwortlich? Eher nicht, oder? Also, wir importieren grundsätzlich nur source packages aus Debian. Der Debian Maintainer ist dafür verantwortlich, dass seine Binärpakete in Debian einwandfrei funktionieren. Mehr braucht er nicht zu tun. Viele Debian Maintainer sorgen aber auch dafür, dass ihre Pakete gut in Ubuntu funktionieren. Aber manchmal machen wir einige Dinge etwas anders, und dann müssen wir eben die Quellpakete von Debian modifizieren. Wir brauchen keine Erlaubnis um Pakete in Ubuntu zu modifizieren. Wenn wir jedoch Probleme im Paket lösen, geben wir unsere Änderungen selbstverständlich über das Debian BTS (bug tracking system) zurück! Desweiteren kann JEDER alle Unterschiede sortiert nach source packages einsehen. Achja, damit wir jetzt nicht aneinander vorbeireden: wir reden im Moment von einem "gewöhnlichem" Debian Paket. Sonderpakete wie gnome, kde, mono, openoffice, etc. sind an sich ja etwas anspruchsvoller. Für solche Gebiete haben wir in Ubuntu TEAMs oder zumindest eine Person, die den Überblick behält, was mit diesen Paketen geschieht.
Ende der Erläuterung durch Reinhard Tartler (siretart)
Die Pakete kommen als Source zu uns und werden auf unsereren build-daemons gebaut.
Geht es noch konkreter? Werden die Pakete jetzt lokal kompiliert, oder von einem Server aus?
Zuerst bei dir, damit du es testen kannst, dann lädst du (als MOTU) das Sourcepaket hoch und es wird automatisch auf allen 4 architekturen gebaut (i386, powerpc und amd64 sind supported und vielleicht bald auch ia64) http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html 🇬🇧 ← das sind aktuelle build logs
Also funktioniert das weitgehend automatisch und ihr müsst nur testen und im Bedarfsfall korrigieren?
Eher nicht, wir haben Leute, die sich speziell mit irgendwas auskennen und das wird respektiert und anerkannt, aber generell hat jeder das Recht an jedem Paket etwas zu ändern. Ich denke, das ist ein entscheidender Vorteil, weil es keine komplizierten Prozesse gibt, wer wann wo was machen darf und das Klima ist so gut, dass jeder miteinander redet und ein gutes Klima ist mir persönlich sehr wichtig. Das ist der aktuelle Release cycle: http://udu.wiki.ubuntu.com/BreezyReleaseSchedule 🇬🇧 Nach einem Freeze fließen nur noch Securityfixes und äußerst wichtige Bugfixes in dem Release ein.
Gibt es weitere Schnittstellen zwischen Debian und Ubuntu?¶
Hierzu eine Erläuterung von Rainhard Tartler (siretart), Oliver Grawert (ogra) und Stephan Hermann (\sh) Chatlog vom 21. Juni und 2. Juli:
Wir versuchen auch unsere neuen Pakete nach Debian zu bringen: UniverseNewPackages ist die Liste dafür. Problematisch ist, dass man dafür einen Uploader braucht und es ist weniger einfach als in Ubuntu. UniverseNewPackages sind allgemein gesagt Pakete, die WIR schon im Archiv haben, aber nicht in Debian enthalten sind.
Es gibt einen sync Mechanismus von Debian nach Ubuntu, aber nicht umgekehrt für neue Pakete.
Die beiden sehr verschiedenen maintenance Modelle machen das recht schwierig. Wir müssen Lösungen finden, die für beide Gruppen probat sind. Es dauert halt seine Zeit. Wenn ich ein Paket baue, dann kann es jeder nutzen und evtl. auch anpassen. In Debian herrscht Eigentumsrecht - in ubuntu siehst du eher Teams.
Normalerweise ist es unter Debian so, dass es pro Paket einen Maintainer gibt (evtl. auf Lebenszeit), und du hast den "Intent To Package" Mechanismus. Intent To Package - Paketvorschlag / (ITP)-Eintrag ist sozusagen ein Hinweis, dass jemand daran arbeitet und niemand anderes das gleiche Paket bearbeiten sollte.
Das "Problem" sind die ITPs in Debian. Ein ITP ist ein Bug der um ein bestimmtes Paket bittet. Im Gegensatz zu Debian hat Ubuntu keine direkten Maintainer, d.h. jeder kann ein Paket anpacken, fixen, erweitern etc. Wenn ich ein ITP "file" muss ich auch der Maintainer werden. Ein "bug filen" ist der Jargon für "einen Bug melden, oder einen Eintrag in einem Bugzilla vornehmen. So können wir nicht einfach automatische "ITP bugs filen" - was das Optimum wäre - mit einem Hinweis, dass Ubuntu schon ein Paket hat und das Debian nur nehmen müsste.
Was wäre hier noch vorstellbar? So eine Übersichtsseite von Paketen "In ubuntu but not in debian"?
Man könnte z.B. einfach ein monatliches Newsletter an debian-devel schicken.
Erschweren weitere Faktoren die Zusammenarbeit?
Unser Upstream geht nur in Richtung Debian, aber man muss das Ganze in einem größeren Zusammenhang sehen. Wir haben es hier mit 3 bzw 4 Distributionen zu tun haben: debian, ubuntu, progeny und linspire.
Ok. Es gibt also unterschiedliche maintenance Modelle? Wo liegen die Gemeinsamkeiten?
Einige Leute arbeiten in beiden Projekten. Diese bilden an sich schon eine Schnittstelle. Am 21. Juni gab es z.B ein Meeting zwischen "ubuntu" und "debian". Die Zusammenfassung/Ergebnisse von dem Meeting ist zu finden unter https://wiki.ubuntu.com/MOTUNewPackagesPolicy 🇬🇧
Wir haben uns darauf geeinigt, dass wir die Pakete erstmal aufnehmen und einen RFS Bug im debian BTS anlegen (= durch die ftpmaster von debian anlegen lassen). Mit BTS ist das debian Bug Tracking System, also die debian Fehlerdatenbank gemeint.
technischer Hintergrund erklärt von Reinhard Tartler (siretart):
Der sync Mechanismus von Debian nach Ubuntu geht weiterhin automatisch (abgesehen von Paketen mit ubuntu Änderungen), aber nicht umgekehrt für neue Pakete. Von ubuntu nach Debian filen wir RFS bugs. Debian kennt die Bugtypen RFS (Request for Package, http://www.debian.org/devel/wnpp/requested) 🇩🇪 und ITP (Intent to package, http://www.debian.org/devel/wnpp/prospective 🇩🇪). Interessierte Debianbetreuer koordinieren sich damit untereinander. Die ITP/RFP's "gehen" gegen das Pseudopaket "wnpp"; da werden solche Bugs gesammelt. Alles wird im Detail beschrieben unter http://www.debian.org/devel/wnpp/ 🇩🇪.
Das hat mit uns "ubuntus" nur insofern zu tun, dass etliche von uns gleichzeitig debian Maintainer sind, und dass wir für die Richtung ubuntu → debian diesen Kommunikationskanal benutzen. Wichtig bei einem solchen Meeting ist also, dass man sich mit debian über eine Prozedur eninigt.
Gibt es auch Ansätze seitens Debian?
Debian-Entwickler Joachim Breitner z.B. will das auseinander driften von Debian und Ubuntu verhindern. Dazu gründete er das Projekt Utnubu, das die Teile von Ubuntu nach Debian bringen soll, die in Debian fehlen. Um sich zunächst über die Unterschiede zwischen Debian und Ubuntu klarzuwerden, stellt eine Gruppe Listen in Debian fehlender Pakete bereit und stellt für beidseitig vorhandene Pakete die Unterschiede in Form von Patches dar. Auf einer nach Maintainer sortierten Liste können Debian-Entwickler die Modifikation ihrer Pakete seitens Ubuntu nachvollziehen und Brauchbares übernehmen.
Wie wird man jetzt MOTU? Eine Kurzfassung?¶
Auf dem Weg dahin gibts mehrere Stationen...
Die erste ist natürlich sich etwas in der MOTU Landschaft zu bewegen; Sei es bei einer großen Fix-Aktion auszuhelfen (imho der beste Weg) oder ein eigenes Paket zu packen. Einfach dazu lernen, Leute fragen und etwas mit dabei sein. Im Channel wird viel geredet, da schnappt man schon auf, was als nächstes dran ist. Der Channel ist jedem zugänglich und wird auch immer offen bleiben. Die IRC Logs verschwinden nicht ins Nirvana, sondern können jederzeit unter http://people.ubuntu.com/~fabbione/irclogs/ 🇬🇧 eingesehen werden.
Nächster Schritt ist eine Wiki-Seite auf wiki.ubuntu.com/VornameNachname anzulegen und zu beschreiben, welche Ideen man hat, was man gerne macht, wie man sich in Ubuntu engagieren möchte. Diese Seite verlinkt man dann auf CommunityCouncilAgenda. Da wird man zum "Member" gemacht. Jeder, der sich ein wenig engagiert hat (sei es Artwork, Packaging, Forumarbeit, Übersetzungen), kann das machen. Als Member wird man in Zukunft auch eine coole @ubuntu.com Adresse bekommen und man gehört "dazu". Man muss allerdings einen gpg key haben und damit den Code of Conduct "unterschreiben". Hierfür ist eine Anmeldung an https://launchpad.net/ 🇬🇧 erforderlich.
Wie wurde dein Schlüssel signiert?
Ich hab einen befreundeten Debian-Developer gefragt. Wer das nicht kann, kann auf biglumber.com nachschauen, das ist oft auch erfolgreich. Ich hatte für eine KeySigning Party mal alle auf biglumber aus meiner Stadt angeschrieben und es kamen tatsächlich 4.
Danach arbeitet man weiter im MOTU Team und man setzt sich im Wiki auf die MaintainerCandidates Seite. Die Liste wird im TechnicalBoard Meeting besprochen und wenn ogra (Oliver Grawert ist der zweite Motu Leiter) und ich mit der Arbeit zufrieden sind (und die anderen natürlich auch) wird derjenige in den Uploader-Keyring aufgenommen und ist ein MOTU.
Die Atmosphäre ist sehr gut und das ist mir persönlich SAUwichtig. Jeder, der mithelfen will ist absolut eingeladen. Alle Ideen sind herzlich willkommen, auch grade im Motu-Ablauf und paketieren lernt man auch schnell. http://wiki.ubuntu.com/MOTUMeeting 🇬🇧 haben wir auch ab und an, und die sind auch öffentlich.
Was empfiehlst du also konkret? Wie fange ich an?¶
Ich denke generell ist es sinnvoll bei den großen Fixaktionen mitzuhelfen, ein Paket neu zu bauen, ein wenig was dran zu ändern und einen Rahmen zu haben, in dem man sich erstmal bewegt. Kurz vor dem Release ist es immer besonders hektisch. hektisch == interessant ☺ Viele der 15.000 Pakete sind etwas betagt und brauchen extraviel Liebe, damit wir die Pakete dann auch "funktionierend" ausliefern können. Universe ist zwar nicht auf den CDs/DVDs drauf, aber es gibt immer einen "Stand", der vor dem Release eingefroren wird.
http://wiki.ubuntu.com/PbuilderHowto 🇬🇧 kann ich dir für Paketierung nur ans Herz legen. Damit hast du ein absolut separates build-environment, darin lässt sich alles testen. Am besten mit apt-get source <paket> mal ein paket runterladen und reinschauen es dann ein wenig aendern, im pbuilder testbauen lassen, ... Eine weitere Empfehlung zum paketieren ist CDBS : https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS 🇬🇧
Kann man den Lernprozess beschleunigen?
Hierzu gibt es revu: https://wiki.ubuntu.com/REVU 🇬🇧. Man muss kein Motu oder ubuntu member sein, um auf dem Revu Server Pakete uploaden zu dürfen. Wichtig ist lediglich, dass ein signiertes GPG Key an siretart gesendet wird. Dadurch hat man die Chance sein eigenes Paket durch Motus und andere erfahrene Paketierer untersuchen zu lassen und ein entsprechendes Feedback zu erhalten.
Wie bist du Motu geworden? Du kommst sicher aus der Debian Ecke, oder?¶
Wenn du auf http://wiki.ubuntu.com/MOTU 🇬🇧 schaust, siehst du, dass ich keiner der ersten war. In meinem Fall hast du Recht. Ich hab Debian schon 5 Jahre benutzt, mich aber vor dem "debian new maintainer" Prozess immer etwas gedrückt, weil mir das zu kompliziert erschien. Die Atmosphäre in #ubuntu-devel war gut, und mich haben Leute ermutigt mit zu machen. Also hab ich irgendwann angefangen mein erstes Paket zu packen. Dann haben 3-4 Leute mit mir geschimpft und ich hab weiter gemacht ☺
Wie fühlt es sich an ein MOTU zu sein?
Du kannst tun und lassen, was du willst und es passt eigentlich immer in deinen Tagesplan ☺ Natürlich ist es auch Verantwortung. Euer Paket installieren nachher hunderte von Usern.
Jetzt gibts dann in der deutschen Dokumentation dann auch eine Seite, auf die sich verweisen lässt, wenn jemand Interesse hat.
Links¶
Paketierung:
http://mako.cc/projects/sa_debian/ 🇬🇧 Die Betrachtung eines Debian Paketes
http://www.ubuntulinux.org/wiki/HowToBuildDebianPackagesFromScratch 🇬🇧 - Eine "Einführung" in die Paketierung
https://wiki.ubuntu.com/PbuilderHowto 🇬🇧 - nützliches Tool beim Bau von Paketen
http://www.ubuntulinux.org/wiki/PackagingTips 🇬🇧 - Paketierungstipps
http://wiki.ubuntu.com/UniverseCandidates 🇬🇧 - das wünschen sich User
http://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue 🇬🇧 - Die berühmte Warteschlange
http://www.debian.org/doc/manuals/maint-guide/index.de.html 🇩🇪 - Maintainer Guide
http://www.ubuntulinux.org/wiki/DeveloperResources 🇬🇧 Entwickler Ressourcen Motu & Co
http://wiki.ubuntu.com/MOTU 🇬🇧 - die MOTUs
http://www.ubuntulinux.org/community/processes/newmember 🇬🇧 - Wie man Mitglied wird
http://www.ubuntulinux.org/wiki/MOTUTeamHowto 🇬🇧 - Howto für angehende Teams
http://wiki.ubuntu.com/MOTUTodo 🇬🇧 - die aktuellen Baustellen
http://www.ubuntulinux.org/wiki/MOTUNewPackages 🇬🇧 - MOTU Neue Pakete
https://wiki.ubuntu.com/MOTUReport 🇬🇧 monatlicher Bericht rundum die Motuwelt Informationen
http://lists.ubuntu.com/archives/breezy-changes/ 🇬🇧 - Änderungen in Breezy
http://popcon.ubuntu.com/universe/index.html 🇬🇧 - Populärste Pakete in UNIVERSE
http://udu.wiki.ubuntu.com/BreezyBounties 🇬🇧 - BreezyBounties (bounties=Prämien)
http://udu.wiki.ubuntu.com/BreezyReleaseSchedule 🇬🇧 - Breezy Release Fahrplan
http://udu.wiki.ubuntu.com/UbuntuDownUnder/BOFs 🇬🇧 - Das wurde in Sydney besprochen
http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals 🇬🇧 - die Breezy Ziele
Build Daemons:
http://www.ubuntulinux.org/wiki/BuildDaemons 🇬🇧 - Was passiert, nach dem ein Paket upgeloadet wurde.
http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html 🇬🇧 - letzte gebaute Pakete Weiteres
http://www.ubuntulinux.org/community/conduct/document_view 🇬🇧 - Code of Conduct
http://www.ubuntulinux.org/wiki/UbuntuProcedures 🇬🇧 Prozesse und Prozeduren
http://www.debian.org/doc/debian-policy/ 🇬🇧 - Das technische Rückgrat von Debian GPG & Co.
http://www.pro-linux.de/berichte/gnupg.html 🇩🇪 - Der GNU Privacy Guard von Stephan Beyer
http://www.cryptnet.net/fdp/crypto/gpg-party.html 🇬🇧 - GnuPG Keysigning Party HOWTO
http://www.ubuntulinux.org/wiki/GPGsigningforSSHHowTo 🇬🇧 - GPGsigningforSSHHowTo
http://unixag.subpath.org/moin.cgi/Veranstaltungen/KeySigning 🇬🇧 - Veranstaltungen/KeySigning
http://www.ploetzli.ch/self/treffen05/keysigning 🇬🇧 - genauer Ablauf einer Keysigning Party
http://linuxreviews.org/howtos/gnupg/ 🇬🇧 GnuPG Privacy Howtos
http://www.biglumber.com 🇬🇧 - Leute, die bereits zum Zeichnen eines Keys berechtigt sind