Suchergebnisse
Suchergebnisse 1-20 von insgesamt 89.
mir ist nicht klar was du mit den kopierbefehlen bezweckst. Das müsste alles von selber gehen. aber der Befehl ist meiner Meinung nach nicht vollständig. Nach mir sollte es heissen Quellcode 1 grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/boot
Wie gesagt geht es um ein suchen ersetzen Problem. Normalerweise nehm ich dazu fast immer sed und es geht. Das Problem liegt aber daran, dass die Daten nicht ganz so homogen sind wie sie sein sollten um ein sicheres Ergebnis zu gewährleisten, zumindest hab ich noch keinen Weg gefunden dass es immer geht. Zur Veranschaulichung ein paar Beispiele: Quellcode 1 2 3 media-libs/libsdl-1.2.15-r9 abi_x86_32 media-libs/alsa-lib-1.1.6-r1 abi_x86_32 x11-libs/libdrm-2.4.92 abi_x86_32 wie kann ich alle Versi...
Der Trick liegt darin, dass jedes Sonderzeichen, wozu der Backslash genauso wie das Leerzeichen mit einem zusätzlichen vorangestellten Backslash maskiert werden muss, dann gehts. Quellcode 1 sed -e 's/Erste/Erste\\\ HD/g' testdatei Wobei der Inhalt von Testdatei Dein zu ändernder Text ist. Zum ändern musst Du dann noch -e gegen -i ersetzen damit sed das auch in der Datei macht und nicht nur anzeigt
Was mir noch gefällt an Gentoo ist folgendes: Wenn mal von einem Paket nicht die aktuellste vom Programmierer des Pakets angebotene Version im Tree vorhanden ist, reicht es oftmals, das ebuild zu kopieren die Versionsnummer auf die noch nicht im Tree vorhandene zu ändern, das Manifest zu erstellen, und das teil zu installieren. So schnell hat man in keinem anderen Linux direkt über das Paketmanagement Software installiert die es eigentlich für die Distribution noch gar nicht gibt.
@hafgan von testing zurück auf stable zu wechseln ist nicht so trivial wie du das beschreibst. Wenn Du das wirklich willst, dann ist entweder mit extrem vielen ausnahmen zu rechnen, die du im testing zweig belassen musst weil die dependencies sich nicht auflösen lassen, oder du musst das system für längere zeit in dem zustand in dem es ist belassen, alle packete einfrieren, und so lange warten bis alle packete aus stable wieder neuer sind als das was du installiert hast. Alle diese Dinge sind ab...
Lass mich mal nen Schuss ins Blaue machen. Die IP ist die des Servers, ABER das nützt Dich nichts, weil Du nicht die Addresse des Servers eintragen musst, sondern die IP Addressen Deiner lxc-container, weil das sind die Rechner, die die Arbeit machen sollen.
Habe mir das ganze nochmal angesehen und vermute den fehler gefunden zu haben. Mit distcc-config --set-hosts musst Du überall alle Rechner die mitmachen sollen eintragen, bei Dir steht da nur einer drin, und das wird vermutlich die IP deines Client Rechners sein, was bedeutet, dass distcc alles local machen will, und da Du dort -l0 hast, wie schon erwähnt macht er nachher eben gar nix weil remote Rechner gibts keine und Lokal soll er nix machen dürfen.
Ich bin mir nicht ganz sicher, und ich glaube auch nicht dass es der wirkliche Grund ist weshalb es nicht geht, aber das hier Zitat MAKEOPTS="-j9 -l0" gefällt mir nicht ganz. mit-lx sagst du nämlich meines Wissens dass , falls die Remote Rechner nicht verfügbar sind nichts kompiliert wird, denn bei Dir steht da ja NULL was somit heisst das NULL Threads lokal benutzt werden sollen. Und somit macht der Rechner vermutlich gar nix, wenn distcc keine Rechner erreicht.
Eine Methode die funktionieren sollte unabhängig ob systemd oder openrc verwendet wird, ist folgende ntp mit Networkmanager das script ist für openrc, muss also für systemd noch angepasst werden aber geht sicher zudem muss beachtet werden, dass gegebenenfalls entweder eth0 gegen enp.... ersetzt werden muss, oder als boot parameter net.ifnames=0 gesetzt werden muss damit die schnittstelle auch wirklich eth0 heisst was auch wichtig ist dass der ntp Dienst NICHT direct aktiviert wird mit dieser met...
Hm eigenartig. Dann ist das wohl wirklich ein anderes Problem, und ich kann nicht wirklich helfen, aber ich kann nur sagen, dass bei mir alles funktioniert in Bezug auf Virtualbox in unstable gentoo, und ich nutze das schon lange nur noch aus unstable. und zwar in beide Richtungen VirtualBox aus unstable um guests zu starten, und umgekehrt auch Gentoo-System unstable gestartet in VirtualBox mit guest-additions.
Ok das sieht soweit in Ordnung aus. Gib mir mal auch noch die Ausgabe von Quellcode 1 emerge -pv qt-meta dann mal falls hier auch qtquick rein will qtquick ohne Version maskieren nochmals emerge -pv qt-meta, und dann die ganzen required die dann gehagelt kommen werden auch noch dazugeben
Zitat Die Ausfuehrung von sudo loadekys de im Terminal ist erfolchreich. Im X nicht. das ist ganz logisch, denn unter X bewirkt der Befehl rein gar nix, da X ein anderes Tastaturlayout verwendet. Dieses wird entweder über ein Tool des jeweiligen DE eingestellt, oder per command-line mit Quellcode 1 setxkbmap de
Ich habe so wie es aussieht genau das selbe Problem, und ich kann Dir nur sagen ein umstieg auf OpenRC würde nichts bringen, denn bei mir verwende ich OpenRC. Und alles was ich machen kann ist mit Quellcode 1 CTRL-ALT-F2 auf ne konsole zu wechseln und Quellcode 1 /etc/init.d/sddm restart zu tippen meistens gehts dann wieder
Hm Eigenartig. Du hast aber hoffentlich nicht vielleicht nachdem Du der Anleitung gefolgt bist vor dem emerge von xf86-video-virtualbox noch versehentlich Quellcode 1 emerge --sync ausgeführt? Denn falls dem so ist könntest Du den Versuch nochmals starten. Der emerge von xf86-video-virtualbox funktioniert mit dieser Methode nur bis zum nächsten sync
Sorry ich hab mich verschrieben Du musst Quellcode 1 equery l *qt*
gib mal die Ausgabe von Quellcode 1 equery l *dev-qt* und ob Dein system testing oder stable ist
Siehe das hier das sollte Deine Probleme bezüglich der xf86-video-virtualbox und guest-additions lösen GentooForum.org
Solange Du nicht grad Pech hast, und jemand eine noch unbekannte Sicherheitslücke in Deinem verwendeten Kernel ausnutzt um Dich zu hacken gar keine. Und wenn Du Dich zumindest regelmässig informierst über alle gefundenen Sicherheitslücken und somit informiert bist dass Dein Kernel sicher sein sollte, hast Du nichts zu befürchten.
mittlerweile ist 340.102 ich vermute mal da der so schnell hinter deinem 340.1.1 gekommen ist, das der Dein Problem beheben könnte
So wie es aussieht wurde qtquick1 aus dem tree entfernt, wahrscheinlich weil es in ein anders packet gewandert ist , und somit nicht mehr gebraucht wird. Wenn ich nämlich qt-creator starte und auf neues Projekt gehe, kann ich da Qtquick anwendung auswählen, also sollte das vorhanden sein, und bei mir ist kein qtquick1 installiert. Solltest du einfach mit Quellcode 1 emerge --depclean qtquick1 deinstallieren können, und trotzdem sollkte noch alles funktionieren
