Funktioniert Installation von Paketen bei Release-Canditates?

C

cabriofahrer

Well-Known Member
Mittlerweile ist 9.3-RC2 erschienen, ich würde es gerne mal ausprobieren, insbesondere wegen KMS für Radeon, allerdings nur, wenn sich Pakete einfach mittels 'pkg install' installieren lassen. Vor einiger Zeit stand in Updating, dass in 9-current die Pakete bereits mit xorg_new ausgeliefert werden. Gehe ich also richtig in der Annahme, dass dies für 9.3 dann auch zutrifft und funktioniert das schon mit dem Release-Candidate mittles 'pkg install'?
 
Hm... Das ist eine gute Frage. Ich habe das auch gelesen. Allerdings glaube ich nicht, dass das xorg Paket schon umgestellt wurde. Andererseits ist das aber auch nicht so ganz wild, wenn man das selber macht. Ich nutze hauptsächlich pkg und Ports für ein paar andere Sachen. Ich nutze dann folgendes Skript, um pkg davon abzuhalten meine selbstgebauten Sachen zu überschreiben.
Code: 
#!/bin/sh
pkg lock graphics/dri
pkg lock graphics/libdrm
pkg lock graphics/libGL
pkg lock x11-drivers/xf86-input-keyboard
pkg lock x11-drivers/xf86-input-mouse
pkg lock x11-drivers/xf86-video-intel
pkg lock x11-servers/xorg-server
Und damit werden sie wieder freigeschaltet:
Code: 
#!/bin/sh
pkg unlock graphics/dri
pkg unlock graphics/libdrm
pkg unlock graphics/libGL
pkg unlock x11-drivers/xf86-input-keyboard
pkg unlock x11-drivers/xf86-input-mouse
pkg unlock x11-drivers/xf86-video-intel
pkg unlock x11-servers/xorg-server
Ist nicht gänzlich schön aber nun... Vielleicht gibt's später mal was besseres als pkg lock. Also kann man die Pakete so bequem locken und ein Update durchführen. Dann den Portstree mit portsnap fetch update aktualisieren und ein
Code: 
portmaster `cat ports.txt`
absetzen.
In ports.txt stehen dann einfach nur wieder die selben Sachen drin...
Code: 
graphics/dri
graphics/libdrm
graphics/libGL
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse
x11-drivers/xf86-video-intel
x11-servers/xorg-server
Das ist letztendlich die Möglichkeit immer eigens kompilierte Ports benutzen zu können. Perfekt ist das nicht aber ich wüsste auch nicht, wie man das deutlich besser machen sollte. Die Skripte könnte man sicherlich automatisch mit einer Liste der Programme generieren lassen... Ach ja, es kommt natürlich drauf an, welchen Treiber man benutzt! Ich nutze den intel-Treiber aber man könnte auch wohl einfach den kompletten xorg-drivers Port benutzen.
 
Das neue X.org ist ein eigenes Repo, was per Multirepo-Support zusätzlich zum Hauptrepo eingebunden wird:
Code: 
newxorg : {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/new_xorg",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
 
zuglufttier schrieb:
...
Das ist letztendlich die Möglichkeit immer eigens kompilierte Ports benutzen zu können. Perfekt ist das nicht aber ich wüsste auch nicht, wie man das deutlich besser machen sollte. Die Skripte könnte man sicherlich automatisch mit einer Liste der Programme generieren lassen... Ach ja, es kommt natürlich drauf an, welchen Treiber man benutzt! Ich nutze den intel-Treiber aber man könnte auch wohl einfach den kompletten xorg-drivers Port benutzen.
Zum Vergrößern anklicken....

Danke, wollte gerade fragen, wie man portmaster und pkg unter einen Hut bekommt.
 
Yamagi schrieb:
Das neue X.org ist ein eigenes Repo, was per Multirepo-Support zusätzlich zum Hauptrepo eingebunden wird:
Code: 
newxorg : {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/new_xorg",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
Zum Vergrößern anklicken....

Und wo / wie gehört das genau hin? Folgender Ausganspunkt: Frischinstallation vom 9.3-RC. Beim ersten Ausführen eines 'pkg install' wird erstmal pkg selbst mit den dazugehörigen Konfigurationsdateien heruntergeladen und installiert, also auch das Standardrepo (/etc/pkg/FreeBSD.conf). Und wie kann ich dann mittles 'pkg install' bestimmen, dass das neue xorg installiert wird?
 
Bei mir sieht das so in /usr/local/etc/pkg/repos/FreeBSD.conf aus:
Code: 
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  enabled: yes
}

newxorg : {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/new_xorg",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
Scheinbar überschreibt das Repository newxorg einfach die entsprechenden Pakete.
 
OK Danke, doch folgendes Problem mit dem ATI-Treiber: Wie gesagt probiere ich 9.3-RC2 aus (auf einem Stick installiert). Mit der obigen Konfigurationsdatei werden in der Tat diverse Packages aus dem new_xorg Repo bezogen und installiert. Doch beim Starten von glxgears nur Softwaremodus und die Meldung:

libGL error: Failed to load driver: r600

Dies ist wohl auf die Treiberversion xf86-video-ati-6.14 zurückzuführen, denn für den Betrieb mit KMS wird Version 7.2 benötigt. Ein Blick in die Makefile zeigt folgendes:

.if ${OSVERSION} < 100051 || !defined(WITH_NEW_XORG) usw...

Ich kann also selbst aus den ports nicht die neuere Version von xf86-video-ati kompilieren, da diese wohl nur für FreeBSD 10.0 vorgesehen ist? Könnte ich vielleicht anstatt von "100051" eine andere Zahl mit 9 (welche genau für FreeBSD 9.3?) in die Makefile eintragen, um ATI-Version 7.2 zu bekommen?
 
Mal so ganz nebenbei: Warum nimmst du eigentlich nicht FreeBSD 10? Das sollte das Problem ja lösen ;) Ansonsten kann ich leider nicht viel beitragen. Ich selber habe mich nur mit dem Intel-Treiber rumplagen müssen :D
 
Weil anscheinend HAL mit FreeBSD 10 nicht mehr richtig funktioniert ( http://bsdforen.de/threads/seit-upg...automounten-mit-hal-nicht-mehr-richtig.31096/ )
und auch mein Wlan nicht auf Anhieb beim Start des PC. Dann ist auch newcons nicht vorhanden, so dass ich vorerst noch den Kernel umkompilieren müsste, das ist die Oberpanne des 10.0-Release.

Könnte mir jetzt trotzdem jemand hier sagen, ob ich die Makefile entsprechend ändern kann, damit der Port sich auch mit 9.3 in der Version 7.2 baut?
 
Also, hier gehen mehrere Sachen durcheinander. Beginnen wir mal mit Newcons aka vt(4): Newcons ist ein Konsolenrenderer, der Syscons ersetzen wird. Natürlich ist es schön Newcons zu haben, wenn man KMS nutzen möchte. Denn anders als Syscons schaltet die Konsole nicht ab, sobald KMS die Kontrolle über die Grafikkarte übernimmt. Notwendig ist es allerdings nicht. Auch mit Syscons kann man KMS einwandfrei nutzen, man verliert lediglich die Konsole... Newcons befindet sich derzeit in 11-CURRENT, 10-STABLE und dem kommenden 9.3-RELEASE. Im alten 10.0-RELEASE ist es nicht enthalten. In 11-CURRENT und 10-STABLE wird Newcons einfach über einen Eintrag in der /boot/loader.conf aktiviert, in 9.3-RELEASE wird man voraussichtlich (da ein Last Minute Merge unwahrscheinlich ist) einen eigenen Kernel bauen müssen. Newcons soll irgendwann die Standard-Konsole werden, aber bis dahin sind noch einige Nachteile gegenüber Syscons auszugleichen. So kann Newcons im Moment selbst keine Auflösungen schalten und ist auf einigen Ausgabemodulen, das beste Beispiel ist dort VGA, grottenlahmst.

Zu xf86-video-ati: Die KMS-Module für Radeon-GPUs befinden sich zwar in 9.3, aber aus irgendeinem Grund wird der Userland-Treiber erst ab FreeBSD Version 1000051 mit KMS-Unterstützung gebaut. Ich würde einen Bugreport schreiben oder zumindest mal auf freebsd-x11@ nachfragen. Du kannst die Sperre natürlich mal aus dem Makefile entfernen. Mehr als crashen wird es nicht...
 
Und wer braucht denn noch HAL? Zum automatischen Mounten kannst du auch den devd nehmen oder Kamikazes sysutils/automounter


Edit: Was klappt bei deinem WLAN denn nicht unter 10.0?
 
Yamagi schrieb:
Zu xf86-video-ati: Die KMS-Module für Radeon-GPUs befinden sich zwar in 9.3, aber aus irgendeinem Grund wird der Userland-Treiber erst ab FreeBSD Version 1000051 mit KMS-Unterstützung gebaut. Ich würde einen Bugreport schreiben oder zumindest mal auf freebsd-x11@ nachfragen. Du kannst die Sperre natürlich mal aus dem Makefile entfernen. Mehr als crashen wird es nicht...
Zum Vergrößern anklicken....

Gute Idee, also wie müsste die obige Zeile in der Makefile dann genau aussehen?

lme schrieb:
Und wer braucht denn noch HAL? Zum automatischen Mounten kannst du auch den devd nehmen oder Kamikazes sysutils/automounter


Edit: Was klappt bei deinem WLAN denn nicht unter 10.0?
Zum Vergrößern anklicken....

Ich würde HAL gerne einen Arschtritt verpassen, aber zu den Alternativen Folgendes:

sysutils/automounter von Kamikaze: Das Tool hat keine graphische Einbindung, die gemounteten Medien erscheinen noch nichteinmal in den Filemanagern wie Nautilus, obwohl die Medien in /media eingehängt werden.

sysutils/automount von Vermaden: Hier erscheinen die Medien zwar in Nautilus und lassen sich wieder damit auswerfen, doch kein CD/DVD-Support! Laut Vermaden weil devd keine Unterstützung für CD/DVD hat.

sysutils/pcbsd-utils-qt4: Obwohl auch devd-basiert, mit Unterstützung für CD/DVD und graphischer Einbindung in die Filemanager, allerdings lassen sich die Medien nicht über den Filemanager mounten und wieder auswerfen, sondern nur über den speziellen Icon unten rechts im Tray. Außerdem nur für 10.0 und 64-bit.

Fazit: Nur ein richtig funktionierendes HAL gibt derzeit ein echtes integriertes Desktopfeeling. Es ist ein neuer Dienst speziell für FreeBSD geplant, also abwarten...

Zum Wlan: Unter 9.x startet mein Wlan automatisch, unter 10.0 nicht. Ich muss erst wifimgr aufrufen, root-pw eingeben, "rescan for networks", die Anwendung wifmgr stürzt dann mit Fehlermeldung ab, und erst dann habe ich eine Verbindung. Toll...
 
Also von mir aus auf jeden Fall! Vielleicht könntest du sogar darauf hinarbeiten, dass dein Tool als Abhängikgeit von Gnome / KDE / Mate / Xfce usw. anstatt von HAL mitinstalliert wird? Ich weiss aber nicht, inwieweit das neue Projekt schon eingeplant ist:

http://www.freebsd.org/news/status/report-2014-01-2014-03.html#New-Automounter

Könnte ich trotzdem noch die Antwort bekommen, wie genau die Zeile in der Makefile vom ATI-Treiber auszusehen hätte?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben