Tinderbox ... ich versteh es nicht :(

MateJunk

BSD Fan :-)
Hallo,

folgende Fragen habe ich zu Tinderbox:
  1. (Banale Frage ...) im Web Interface habe ich bei Reason manchmal ein Rotes L. Was heisst das ?
  2. Reason: depend_object = The port is trying to reinstall a dependency that already exists ... Hae ja. Warum installiert Tinderbox erst das bin PKG um dann fest zu stellen, das das bin PKG irgnedwie Falsch/veraltet ist ? Werden denn die Versions nummern der Ports nicht "erhoeht" wenn das PKG sich geaendert hatt ? Und merkt das Tinderbox nicht ?
  3. Zb. finde ich sowas sehr haeufig in den logs:
    pkg_add randrproto-1.2.1.tbz
    skipping randrproto-1.2.1, already added
    Verstehe ich auch nicht. Ich dachte immer das Tindebox fuer jeden Port was es bauen will aus dem Jail Verz. tinderbox/jails/6.2 das 6.2.tar nimmt es in tinderbox/6.2-FreeBSD extrahiert, die fertigen PKG "darin" installiert und dann mit dem bauen des Ports loslegt. Aber warum soll denn schon ein PKG "already added" sein ? Das 6.2.tar ist doch "nackt" ?
  4. Was passiert eigentlich bei folgenden aufruf: ./tinderbuild -b 6.2-FreeBSD -nullfs -updateports
    Ich bin immer von folgende ausgegangen ... Ports Verz. wird aktualisiert ... die Tinderbox Prueft nach welche ports neu sind und baut diese mit den neuen Abhaengikeiten. Nur wie sieht das mit "Neuen" abhaengikeiten aus ? Traegt Tinderbox das selbst in seine Datenbank ein ?
  5. Ist das schlimm, wenn waehrend eines -updateports der Rechner abstuertzt ? Werden die veralteten ports dann nicht mehr beim naechsten -updateports beachtet ?
  6. Was macht ihr zB. wenn ein Port verschoben oder umbenannt wurde und tinderbox rum meckert das es den Port nicht mehr findet ? Kann man das nur Haendisch mit ./tc rmPort ... und dann ./tc addPort .... ?

Fragen ueber fragen ... und alles nur wegen dem Xorg update ;) ...
 
  1. (Banale Frage ...) im Web Interface habe ich bei Reason manchmal ein Rotes L. Was heisst das ?
L = leftovers, also Ports, bei denen nach dem Loeschen des Ports noch Dateien uebrig geblieben sind. D.h. entweder ist die pkg-plist falsch spezifiziert oder es handelt sich um eine Ausnahme (z.B. bei mod_* bei apache22, die immer /usr/local/etc/apache2/httpd.conf anpassen). Die Liste der 'uebriggebliebenen Dateien' steht ziemlich am Ende der zum Port zugehoerigen Logdatei.
 
L = leftovers, also Ports, bei denen nach dem Loeschen des Ports noch Dateien uebrig geblieben sind. D.h. entweder ist die pkg-plist falsch spezifiziert oder es handelt sich um eine Ausnahme (z.B. bei mod_* bei apache22, die immer /usr/local/etc/apache2/httpd.conf anpassen). Die Liste der 'uebriggebliebenen Dateien' steht ziemlich am Ende der zum Port zugehoerigen Logdatei.
Ok, Cool Thanks.

Noch ein Hinweis: Ich habe natuerlich tinderbox immer schoen per pkg_add btw. portupgrade -PP geupdatet .... mir ist ja schon immer dieses upgrade.sh script aufgefallen. Dachte eigentlich das dieses automatisch beim updaten ausgefuehrt wird. Ist aber wohl nicht so, denn ich habe es einfach mal ausgefuehrt. Aenderung von DB Version 2.3.0 -> 2.3.3. Naja vielleicht haben sich damit einige Probs geloest. Trotzdem bestehen noch meine "Verstaendnis fragen".

Bedanke mich schon mal im vorraus fuer eure Antworten.

Gruss
Joerg
 
Ist das schlimm, wenn waehrend eines -updateports der Rechner abstuertzt ? Werden die veralteten ports dann nicht mehr beim naechsten -updateports beachtet ?

Halbwissen: Also soweit es mich immer betroffen hat, ist ein Abbruch kein Problem. Die Datenbank ist dann hoechstes in einem inkonsistenten Zustand ('Ich baue gerade einen Port...'). Die Umgebung wird beim naechsten Kompiliervorgang eh entfernt und neu aufgebaut.
 
# Was passiert eigentlich bei folgenden aufruf: ./tinderbuild -b 6.2-FreeBSD -nullfs -updateports
Ich bin immer von folgende ausgegangen ... Ports Verz. wird aktualisiert ... die Tinderbox Prueft nach welche ports neu sind und baut diese mit den neuen Abhaengikeiten. Nur wie sieht das mit "Neuen" abhaengikeiten aus ? Traegt Tinderbox das selbst in seine Datenbank ein ?
Der Portstree (/usr/ports) wird mit csup/cvsup/portsnap (je nach Wahl) aktualisiert nicht mehr und nicht weniger. Siehe auch das Tinderbox-Readme Kapitel "Using Tinderbox":
http://tinderbox.marcuscom.com/README.html

# Ist das schlimm, wenn waehrend eines -updateports der Rechner abstuertzt ? Werden die veralteten ports dann nicht mehr beim naechsten -updateports beachtet ?
Es wird die Aktualisierung des Portstree abgebrochen. /usr/ports könnte Müll enthalten. Dies ist aber nicht weiter schlimm, da eine erneute Aktualisierung (-updateports) den Datenmüll entfernt.

Ich dachte immer das Tindebox fuer jeden Port was es bauen will aus dem Jail Verz. tinderbox/jails/6.2 das 6.2.tar nimmt es in tinderbox/6.2-FreeBSD extrahiert, die fertigen PKG "darin" installiert
Tinderbox ist eine chroot-Umgebung. Chroot heisst, dass /usr/local/tinderbox/6.2-FreeBSD zu / wird. 6.2.tar wird in dieser leeren / entpackt und so wird die Chroot-Umgebung mit dem Basissystem (/bin etc) bevölkert. Als nächstes wird mit nullfs gewisse für Tinderbox "lebenswichtige" Verzeichnisse umgehängt. Es erscheint /usr/local/tinderbox/portstrees/FreeBSD/ports als /usr/ports in der chroot-Umgebung (gib mal "mount" während einem Tinderbox-Build-Lauf ein).

# Was macht ihr zB. wenn ein Port verschoben oder umbenannt wurde und tinderbox rum meckert das es den Port nicht mehr findet ? Kann man das nur Haendisch mit ./tc rmPort ... und dann ./tc addPort .... ?
Siehe die Shellskripts in der ausführlichen Anleitung unter:
http://wiki.bsdgroup.de/Ports_und_Programme_aktualisieren
Die Shellskripte und der Jails-Aufbau scheinen resistent gegen gröbere Portstree-Änderungen (z.B. xorg) zu sein. Bis jetzt hat sich noch niemand beklagt :rolleyes:

die Tinderbox Prueft nach welche ports neu sind und baut diese mit den neuen Abhaengikeiten. Nur wie sieht das mit "Neuen" abhaengikeiten aus ? Traegt Tinderbox das selbst in seine Datenbank ein ?
Mit /usr/local/tinderbox/scripts/tc addPort -b 6.2-FreeBSD -d <Portsname> -r
versucht Tinderbox alle Abhängigkeiten in die Tinderbox-Datenbank aufzunehmen. Dabei bleibt es meistens beim Versuch, alle Abhängigkeiten erwischt Tinderbox nie. Soll Tinderbox einen Port bauen, so wird der gewünschte Port in jedem Fall kompiliert, auch wenn er schon in der aktuellsten Fassung als Package vorliegt. Die im Makefile eingetragenen Abhängigkeiten (die auch Tinderbox erkennt) werden als Package geholt. Existiert das Package der Abhängigkeit noch nicht, so baut Tinderbox zuerst diesen Port. Leert dann wieder /usr/local/tinderbox/6.2-FreeBSD und beginnt erst dann mit dem Bauen vom Benutzer gewünschten Port. Um aus der Abhängigkeitsproblematik herauszukommen, empfehle ich den Einsatz der unter :
http://wiki.bsdgroup.de/Ports_und_Programme_aktualisieren

vorgestellten Shellskripts ("portupgrade -B <Tinderbox-Shellskript> -aP" ist der Trick).

das nur Haendisch mit ./tc rmPort ... und dann ./tc addPort .... ?
Beachte das rmPort und addPort nur die Tinderbox-Datenbankeinträge bearbeiten. Und die siehst Du im Tinderbox-Webinterface. Für das Package-Bauen sollten diese Datenbankeinträge irelevant sein.

Reason: depend_object = The port is trying to reinstall a dependency that already exists ... Hae ja. Warum installiert Tinderbox erst das bin PKG um dann fest zu stellen, das das bin PKG irgnedwie Falsch/veraltet ist ? Werden denn die Versions nummern der Ports nicht "erhoeht" wenn das PKG sich geaendert hatt ? Und merkt das Tinderbox nicht ?
Wurde die chroot-Umgebung nicht vollständig aufgeräumt? Eventuell konnte Tinderbox einige Altlasten nicht beseitigen. Oder die Tinderbox-Datenbank ist korrupt:

Ich habe natuerlich tinderbox immer schoen per pkg_add btw. portupgrade -PP geupdatet .... mir ist ja schon immer dieses upgrade.sh script aufgefallen. Dachte eigentlich das dieses automatisch beim updaten ausgefuehrt wird. Ist aber wohl nicht so, denn ich habe es einfach mal ausgefuehrt. Aenderung von DB Version 2.3.0 -> 2.3.3.
Bitte Kapitel "Upgrading" vom Tinderbox Readme lesen:
http://tinderbox.marcuscom.com/README.html
 
Zuletzt bearbeitet:
Der Portstree (/usr/ports) wird mit csup/cvsup/portsnap (je nach Wahl) aktualisiert nicht mehr und nicht weniger. Siehe auch das Tinderbox-Readme Kapitel "Using Tinderbox":
http://tinderbox.marcuscom.com/README.html
Yo, das war mir soweit klar. Die Doku kenne ich schon auswendig :). In der Datei ports-supfile steht welcher CVS Server benutzt wird etc.
Mir ging es um Erfahrungswerte.

Es wird die Aktualisierung des Portstree abgebrochen. /usr/ports könnte Müll enthalten. Dies ist aber nicht weiter schlimm, da eine erneute Aktualisierung (-updateports) den Datenmüll entfernt.
Ok, auch soweit klar. Mir ging es um die Frage des tinderbox/builds/6.2-FreeBSD/Makefile. Das Makefile wird ja jedesmal bei einem tinderbuild aufruf erstellt. D.h. bei einem Absturz und dem danach folgenden "neuen" tinderbuild Aufruf, wird das alte Makefile geloescht und ein neues erstellt. Erkennt Tinderbox, das es beim vorherigen "Tinderlauf" noch nicht alle PKGs gebaut hatte ? ... aber ich gehe mal davon aus, das es bei der neu Generierung des Makefiles sowieso den Portstree mit den aktuellen "Tinderbuild Stand (fertig Kompilierte Packages)" vergleicht.
Tinderbox ist eine chroot-Umgebung. Chroot heisst, dass /usr/local/tinderbox/6.2-FreeBSD zu / wird. 6.2.tar wird in dieser leeren / entpackt und so wird die Chroot-Umgebung mit dem Basissystem (/bin etc) bevölkert. Als nächstes wird mit nullfs gewisse für Tinderbox "lebenswichtige" Verzeichnisse umgehängt. Es erscheint /usr/local/tinderbox/portstrees/FreeBSD/ports als /usr/ports in der chroot-Umgebung (gib mal "mount" während einem Tinderbox-Build-Lauf ein).
Yo, ok auch soweit klar.
Siehe die Shellskripts in der ausführlichen Anleitung unter:
http://wiki.bsdgroup.de/Ports_und_Programme_aktualisieren
Die Shellskripte und der Jails-Aufbau scheinen resistent gegen gröbere Portstree-Änderungen (z.B. xorg) zu sein. Bis jetzt hat sich noch niemand beklagt :rolleyes:
Hey, cool. Das Howto ist ja ziehmlich umfangreich. Werd ich mir aufjedenfall die Tage mal anschauen/durchlesen. Bin nur etwas verwirrt weil es wohl noch ein Wiki gibt ? Hatte bis jetzt immer in wiki.bsdforen.de reingeschaut. An einer Stelle faende ich praktischer aber egal. Hauptsache Infos/Howtos :).
Bzgl. skript ... hatte mir auch schonmal ein Shellskript dafuer geschrieben. War aber zu "einfach". Werd mir deins aufjedenfall mal anschauen.
Mit /usr/local/tinderbox/scripts/tc addPort -b 6.2-FreeBSD -d <Portsname> -r
versucht Tinderbox alle Abhängigkeiten in die Tinderbox-Datenbank aufzunehmen. Dabei bleibt es meistens beim Versuch, alle Abhängigkeiten erwischt Tinderbox nie. Soll Tinderbox einen Port bauen, so wird der gewünschte Port in jedem Fall kompiliert, auch wenn er schon in der aktuellsten Fassung als Package vorliegt. Die im Makefile eingetragenen Abhängigkeiten (die auch Tinderbox erkennt) werden als Package geholt. Existiert das Package der Abhängigkeit noch nicht, so baut Tinderbox zuerst diesen Port. Leert dann wieder /usr/local/tinderbox/6.2-FreeBSD und beginnt erst dann mit dem Bauen vom Benutzer gewünschten Port. Um aus der Abhängigkeitsproblematik herauszukommen, empfehle ich den Einsatz der unter :
http://wiki.bsdgroup.de/Ports_und_Programme_aktualisieren
vorgestellten Shellskripts ("portupgrade -B <Tinderbox-Shellskript> -aP" ist der Trick).
Ok. Wie gesagt. Werds mir die Tage vornehmen.
Beachte das rmPort und addPort nur die Tinderbox-Datenbankeinträge bearbeiten. Und die siehst Du im Tinderbox-Webinterface. Für das Package-Bauen sollten diese Datenbankeinträge irelevant sein.
Ok fuers bauen schon, aber fuer den "Build Status" der Packages, also welches Packages ist mit welchen Versions Stand fertig kompiliert, dafuer gibt es Datenbank eintraege. Wie sollten denn ansonsten -updateports den Status "erfahren" welche Packages neu ertellt werden muessen und daraus das builds/6.2-FreeBSD/Makefile zu erstellen. Deswegen muss man diese Ports doch auch per ./tc addPort in die Datenbank eintragen lassen.
Wurde die chroot-Umgebung nicht vollständig aufgeräumt? Eventuell konnte Tinderbox einige Altlasten nicht beseitigen. Oder die Tinderbox-Datenbank ist korrupt:
Hm, das ist ne gute Frage, die ich mir ja auch gestellt habe. Aber wie kann das bzgl. chroot passieren ? Wird denn die chroot Umgebung nicht fuer jedes neu zu bauende Packages neu in tinderbox/6.2-FreeBSD extrahiert ? Dann wird doch jedesmal eine neues "nacktes" chroot/jail fuer den Port bereitgestellt, oder irre ich mich ?
Bitte Kapitel "Upgrading" vom Tinderbox Readme lesen:
http://tinderbox.marcuscom.com/README.html
Ja klar ... ist mir auch immer aufgefallen (habs halt nicht so intensiv gelesen). Bloss hab ich gedacht das das automatisch bei einem Updaten des PKG passiert. Habe mich geirrt.

Erstmal dank ich dir Andreas fuer deine sehr Ausfuehrliche Antwort :). Es hatt mir aufjedenfall schonmal weiter geholfen und hatt eigentlich soweit alles bestaetigt, was ich mir sowieso schon gedacht hatte. War nur etwas verunsichert weil ich soviele depend_object bei einem ./tinderbuild -b 6.2-FreeBSD -nullfs -updateports x11/xorg hatte. Was da nun kaputt bei mir war/ist muss ich dann wohl mal weiter suchen.
 
Dann wird doch jedesmal eine neues "nacktes" chroot/jail fuer den Port bereitgestellt, oder irre ich mich ?
Vor dem Auspacken des 6.2.tar wird ein "rm -R" über /usr/local/tinderbox/6.2-FreeBSD durchgeführt.

Erkennt Tinderbox, das es beim vorherigen "Tinderlauf" noch nicht alle PKGs gebaut hatte ?
Erst beim erneuten Bauen des gleichen Ports. Wenn im Verzeichnis /usr/local/tinderbox/packages/6.2-FreeBSD/All/ das entsprechende Package fehlt.
 
Ok, thanks nochmals Andreas :)

Und hier schon wieder die naechste Frage:
Ich habe nach den ganze depend_object problemen in meiner tinderbox folgendes gemacht:
./tinderbuild -b 6.2-FreeBSD -cleanpackages x11/xorg
-cleanpackages -> removes all packages already built for the specified Build
Kann das sein das er dabei alle Pakete loescht von das das Paket x11/xorg abhaengig ist und zusaetzlich alle Pakete loescht von denen x11/xorg abhaengig sind ?
Ich wollte eigentlich nur das tinderbox alle x11/xorg Pakete loescht die x11/xorg als BUILD_DEPs bzw. DEPs braucht.
In beiden Wikis habe ich nix hierzu gefunden.

Naja, aufjedenfall habe ich jetzt keine einzigen depend_object Probleme mehr. :) ...
 
Zurück
Oben