Am 31.03.2005 um 03:05 schrieb Alexander Dalloz:
Darf ich mal kräftig "aua!" sagen? Warum meinen nur so viele User, sie könnten so mir nichts dir nichts irgendwelche RPMs problem- und risikolos auf ihr System knallen, die sie auf irgendwelchen RPM Suchmaschinen / Referenzierungsseiten entdeckt haben?
Darf ich mal fragen, was eine derartig unnötige Aussage soll? Von einem doch stark vertetenen Ratgeber in dieser ML hätte ich einen derartigen Kommentar nicht erwartet, sondern lieber mal einen konstruktiven Beitrag zum eigentlichen Problem. Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin ich erstmal zufrieden. Die User machen das vermutlich, weil sie sich auf das Paketmanagment vom RPM verlassen und nunmal bei jedem Programm und jeder Distribution die Installation anders verläuft. Woher soll man denn bei jedem Paket wissen, das zudem noch von apt-get automatisch installiert wird, ob da jetzt alles 100% auf mein System passt? Ich für meinen Teil bin froh, dass ich schon manche Pakete selbst kompilieren konnte und daraus RPMS erstellen konnte, da Installation von Software unter Linux nunmal noch ein relativ aufwendiger Akt im vergleich zu anderen OS wie Windows oder Mac OS X ist. Ich für meinen Teil bin definitiv eher der Anwendertyp und überlasse den Rest anderen Leuten die sich damit auskennen. Doch find ich, solche Kommentare wie oben, haben in einer konstruktiven ML (dachte ich zumindest immer) nichts zu suchen. Man braucht sich nicht über die noch relativ schwache Akzeptanz von Linux bei der Hauptschicht der PC-Nutzer zu wundern, wenn man sich solche Kommentare anhören soll. Ich benutze nun schon seit ein paar Jahren Linux (man beachte BENUTZE!) und war bisher eigentlich immer recht zufrieden mit der Hilfe und der Art wie sie geführt wurde, da in der "Linux-Welt" diese Hochnäßigkeit mancher User noch nicht so weit verbreitet ist. Ich fände's sehr schade, wenn sich das nun anders entwickelt.
Gruß
Cedric Laczny
Am Donnerstag, den 31.03.2005, 09:05 +0200 schrieb Cedric Laczny:
Am 31.03.2005 um 03:05 schrieb Alexander Dalloz:
Darf ich mal kräftig "aua!" sagen? Warum meinen nur so viele User, sie könnten so mir nichts dir nichts irgendwelche RPMs problem- und risikolos auf ihr System knallen, die sie auf irgendwelchen RPM Suchmaschinen / Referenzierungsseiten entdeckt haben?
Darf ich mal fragen, was eine derartig unnötige Aussage soll?
Sie trifft ein großes Problem. Nicht das gerade vorliegende technische (das du lösen willst), aber ein Problem, das scheinbar durch unsachgemäßes einspielen von RPMS erst entstanden ist.
Von einem doch stark vertetenen Ratgeber in dieser ML hätte ich einen derartigen Kommentar nicht erwartet, sondern lieber mal einen konstruktiven Beitrag zum eigentlichen Problem.
Ich glaube, das es viele hier auf den ML gibt, die von Problemen schlicht genervt sind, wo User durch "ungeschicktes" Einspielen von "nicht offiziellen" (nicht core, nicht extras) RPMS Schwierigkeiten haben. Daher wollte Alexander wohl mal auf das eigentliche Problem aufmerksam machen. Ich finde das richtig. Danke Alexander.
Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin ich erstmal zufrieden.
Nicht böse sein, aber transcode kompilieren ist nichts für nicht Linux- Gurus imho. Transcode haben doch wohl dag, atrpms, livna und freshrpms alle vorkompiliert im Angebot.
Die User machen das vermutlich, weil sie sich auf das Paketmanagment vom RPM verlassen und nunmal bei jedem Programm und jeder Distribution die Installation anders verläuft.
Dann muss man den usern wohl erklären, das das nicht so ist. Machen wir ja gerade hier. ;-)
Woher soll man denn bei jedem Paket wissen, das zudem noch von apt-get automatisch installiert wird, ob da jetzt alles 100% auf mein System passt?
Nur apt-get Sourcen eintragen, denen du traust. Die Ansichten, welche das sind, Variieren leider. Siehe fedorafaq, die haben das afaics eigentlich ganz Schick gelöst. Nur core, extras und livna, alles andere bei bedarf iirc.
Ich für meinen Teil mag keine RPM repositories, die Pakete aus der eigentlichen Distribution ersetzen -- das macht erfahrungsgemäß nur Probleme. Damit macht man imho eine neue Distribution auf. Anfragen dazu sollten dann auch von der RPM Quelle gepflegt werden. Also nicht fedora- de-list@redhat.com !
Ja, es mag Gründe geben, Pakete aus Core zu ersetzen -- ich habe nichts dagegen, wenn man es ausdrücklich kennzeichnet. Ich will aber nicht, dass, wenn ich Repro Foo eintrage, um bar zu installieren, dabei dann Xorg oder der Kernel von foo installiert wird (*fiktives* Beispiel).
CU thl
Am Do, den 31.03.2005 schrieb Thorsten Leemhuis um 9:50:
Sie trifft ein großes Problem. Nicht das gerade vorliegende technische (das du lösen willst), aber ein Problem, das scheinbar durch unsachgemäßes einspielen von RPMS erst entstanden ist.
Dies lässt sich dann sicher auch auf nicht sarkastische und auch teils überhebliche Weise mitteilen. Mag sein, dass es schon spät war und evtl. deswegen dieser Ton angeschlagen wurde, das ist allerdings noch keine "Entschuldigung" für solch eine Tonwahl. Wie man an der Mail von Thorsten Leemhuis gesehen hat, geht das Ganze auch auf pur sachlicher Ebene, oder mit so versteckter Ironie, dass ich sie zumindest nicht entdecken kann :)
Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin ich erstmal zufrieden.
Nicht böse sein, aber transcode kompilieren ist nichts für nicht Linux- Gurus imho. Transcode haben doch wohl dag, atrpms, livna und freshrpms alle vorkompiliert im Angebot.
Das von apt-get installierte transcode sollte doch auch laufen, oder? Ich hatte allerdings da Probleme, da ein Konvertieren von mpeg nach avi immer mit einem Speicherzugriffsfehler direkt abgebrochen wurde und zudem einige Codecs nicht liefen, obwohl die entprechenden Bibliotheken vorlagen (soweit ich kontrolliert hab, auch an der richtigen Stelle) Konvertieren von avi in mpeg geht, ebenso funktioniert reines tcextract. Darum dachte ich mir, dass irgendwas schief gelaufen sein muss und wollte mir dann mein eigenes transcode schustern.
Nur apt-get Sourcen eintragen, denen du traust. Die Ansichten, welche das sind, Variieren leider. Siehe fedorafaq, die haben das afaics eigentlich ganz Schick gelöst. Nur core, extras und livna, alles andere bei bedarf iirc.
Da lag nun leider auch ein Missverständnis meinerseits vor, ich dachte irgendwie, livna wäre nicht so gerne gesehen von Fedora. Die KDE-Repositories hab ich ja von der freshrpms Seite, könnte mich aber auch täuschen. Das sind zumindest mal die Einträge in /etc/apt/sources.list: ## kde-redhat repository(s) for RedHat/Fedora RHREL rpm http://apt.kde-redhat.org/apt kde-redhat/fedora/2/i386 stable rpm http://apt.kde-redhat.org/apt kde-redhat/all stable
Gruß
Cedric Laczny
Am Donnerstag, den 31.03.2005, 10:12 +0200 schrieb Cedric Laczny:
Am Do, den 31.03.2005 schrieb Thorsten Leemhuis um 9:50:
Sie trifft ein großes Problem. Nicht das gerade vorliegende technische (das du lösen willst), aber ein Problem, das scheinbar durch unsachgemäßes einspielen von RPMS erst entstanden ist.
Dies lässt sich dann sicher auch auf nicht sarkastische und auch teils überhebliche Weise mitteilen. Mag sein, dass es schon spät war und evtl. deswegen dieser Ton angeschlagen wurde, das ist allerdings noch keine "Entschuldigung" für solch eine Tonwahl. Wie man an der Mail von Thorsten Leemhuis gesehen hat, geht das Ganze auch auf pur sachlicher Ebene, oder mit so versteckter Ironie, dass ich sie zumindest nicht entdecken kann :)
Ich kann sarkastischer und heimtückischer, aber ich will ja hier keinen großen Flamewar los treten. ;-)
Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin ich erstmal zufrieden.
Nicht böse sein, aber transcode kompilieren ist nichts für nicht Linux- Gurus imho. Transcode haben doch wohl dag, atrpms, livna und freshrpms alle vorkompiliert im Angebot.
Das von apt-get installierte transcode sollte doch auch laufen, oder?
Klar. Aber wenn nicht sollte man sehen das man das Problem mit der Repro klären sollte, von er man das Ding bezogen hat. Dann haben nämlich alle anderen auch was von dem Fix 8so wie es bei Open-Source sein sollte), und nicht nur jeder einzelne in seinem stillen Kämmerlein die Arbeit (und die Freude, wenn es dann läuft).
Ganz davon abgesehen, dass das problem auch daran liegen *könnte*, das da libs installiert sind, die nicht mit dem vorkompilierten Transcode klarkommen.
Nur apt-get Sourcen eintragen, denen du traust. Die Ansichten, welche das sind, Variieren leider. Siehe fedorafaq, die haben das afaics eigentlich ganz Schick gelöst. Nur core, extras und livna, alles andere bei bedarf iirc.
Da lag nun leider auch ein Missverständnis meinerseits vor, ich dachte irgendwie, livna wäre nicht so gerne gesehen von Fedora.
So weit ich das beurteilen kann ist das eher anders rum. Aber das kommt auch wieder auf die Sichtweise an -- klar gibt es einige die livna nicht mögen.
livna ersetzt dir auf jeden fall keine Pakete aus core -- dag, atrpms und kde-redhat machen das iirc.
Die KDE-Repositories hab ich ja von der freshrpms Seite, könnte mich aber auch täuschen. Das sind zumindest mal die Einträge in /etc/apt/sources.list: ## kde-redhat repository(s) for RedHat/Fedora RHREL rpm http://apt.kde-redhat.org/apt kde-redhat/fedora/2/i386 stable rpm http://apt.kde-redhat.org/apt kde-redhat/all stable
Ahh, da kommt das neuere vorbis her.
CU thl
Am Do, den 31.03.2005 schrieb Thorsten Leemhuis um 10:42:
Klar. Aber wenn nicht sollte man sehen das man das Problem mit der Repro klären sollte, von er man das Ding bezogen hat. Dann haben nämlich alle anderen auch was von dem Fix 8so wie es bei Open-Source sein sollte), und nicht nur jeder einzelne in seinem stillen Kämmerlein die Arbeit (und die Freude, wenn es dann läuft).
Ganz davon abgesehen, dass das problem auch daran liegen *könnte*, das da libs installiert sind, die nicht mit dem vorkompilierten Transcode klarkommen
## kde-redhat repository(s) for RedHat/Fedora RHREL rpm http://apt.kde-redhat.org/apt kde-redhat/fedora/2/i386 stable rpm http://apt.kde-redhat.org/apt kde-redhat/all stable
Ahh, da kommt das neuere vorbis her.
Und was heisst das? Klappt es,wenn ich die untere Zeile weglasse, die veranlasst apt-get "unpassende" Pakete zu installieren,oder?
Gibt es irgendwelche Massnahmen (die dann bitte auch erklären :) ) die ich hier auf meinem System ergreifen kann, damit es wieder alles zueinander passt, OHNE direkt neu zu installieren?
Gruß
Cedric Laczny
Am Donnerstag, den 31.03.2005, 11:11 +0200 schrieb Cedric Laczny:
Am Do, den 31.03.2005 schrieb Thorsten Leemhuis um 10:42:
Klar. Aber wenn nicht sollte man sehen das man das Problem mit der Repro klären sollte, von er man das Ding bezogen hat. Dann haben nämlich alle anderen auch was von dem Fix 8so wie es bei Open-Source sein sollte), und nicht nur jeder einzelne in seinem stillen Kämmerlein die Arbeit (und die Freude, wenn es dann läuft).
Ganz davon abgesehen, dass das problem auch daran liegen *könnte*, das da libs installiert sind, die nicht mit dem vorkompilierten Transcode klarkommen
## kde-redhat repository(s) for RedHat/Fedora RHREL rpm http://apt.kde-redhat.org/apt kde-redhat/fedora/2/i386 stable rpm http://apt.kde-redhat.org/apt kde-redhat/all stable
Ahh, da kommt das neuere vorbis her.
Und was heisst das?
Es bezog sich auf eine Mail von Michael Schwendt in diesem Thread, wo er fragte, wo denn das neuere vorbis her kam.
Klappt es,wenn ich die untere Zeile weglasse, die veranlasst apt-get "unpassende" Pakete zu installieren,oder?
Naja, die Pakete sind ja schon drauf. "Ja dann ist es zu spät, zu spät, ..." (Ärzte? ach, egal)
Wenn dann müssten beide weg -- eins ohne das andere geht vermutlich nicht (sprach der Gnome Anwender, und fragte sich wiedereinmal, warum das kde-redhat Projekt nicht mit fedora besser zusammenarbeiten kann, damit kde-redhat obsolet ist [nein, bitte keine Antworten, es ist mir egal, ich will es nicht Wissen])
Gibt es irgendwelche Massnahmen (die dann bitte auch erklären :) ) die ich hier auf meinem System ergreifen kann, damit es wieder alles zueinander passt, OHNE direkt neu zu installieren?
Das ist nicht einfach. Gucken welche Pakete von kde-redhat sind (hint: rpm parameter --queryformat -- siehe man-page). Die Deinstallieren, apt- sources (warum eigentlich kein yum, das Bestandteil von core ist -- ach, egal) und das Fedora-KDE wieder einspielen. Aber haue mich nicht wenn es nachher trotzdem nicht geht.
Man könnte auch erstmal versuchen *vorbis* zu deinstallieren und das von fedora-core testhalber einzuspielen (Warnung: das bringt das kde-redhat durcheinander und ist auch nicht ungefährlich) CU thl
On Thu, 31 Mar 2005 10:42:19 +0200, Thorsten Leemhuis wrote:
Das von apt-get installierte transcode sollte doch auch laufen, oder?
Klar. Aber wenn nicht sollte man sehen das man das Problem mit der Repro klären sollte, von er man das Ding bezogen hat. Dann haben nämlich alle anderen auch was von dem Fix 8so wie es bei Open-Source sein sollte), und nicht nur jeder einzelne in seinem stillen Kämmerlein die Arbeit (und die Freude, wenn es dann läuft).
Mehr als das.
Die von mancher Presse als "Linux Bewegung" bezeichneten, im Internet auftretenden Nutzer sollten alles daran setzen, daß wild und kompliziert wirkende Compilierungsorgien in der Öffentlichkeit nicht wie eine Pflichtübung erscheinen.
Und wenn ein Newbie doch hinter die Kulissen schauen und Selbstcompilierung in Angriff nehmen möchte, sollte dies mit größter Vorsicht und Sorgfalt bei der Planung und Ausführung ablaufen. Als Grundgerüst dazu bieten sich die über 1600 Pakete aus Fedora Core an, die zweifelsohne zusammen funktionieren. Nicht erst Fragen stellen, nachdem Pakete ausgetauscht, entfernt oder Paketinhalte überschrieben wurden.
"Wir", d.h. die "Fedora Community", haben ein wachsendes Angebot von Paketerstellern, die es zu unterstützen gibt.
Wenn ein per yum/apt-get aus einem Repository bezogenes Paket in seiner bestimmten Betriebssystemumgebung nicht funktioniert, gehört es zum guten Ton, diesen Fehler zu melden. Wo ggf. Sprachbarrieren existieren, hat die Community im Prinzip Nachholbedarf. Es kann nicht sein, daß Programme eingedeutscht werden, Webseiten und Bugzilla Systeme jedoch aussschließlich auf Englisch sind. Ist in erster Linie aber eine Frage der Resourcen und damit erstmal nebensächlich.
Nur apt-get Sourcen eintragen, denen du traust.
Nur nebenbei bemerkt, wie die Vertrauensgewinnungsphase aussieht und um welche Art von Vertrauen es geht, ist offen.
Die Ansichten, welche das sind, Variieren leider. Siehe fedorafaq, die haben das afaics eigentlich ganz Schick gelöst. Nur core, extras und livna, alles andere bei bedarf iirc.
Da lag nun leider auch ein Missverständnis meinerseits vor, ich dachte irgendwie, livna wäre nicht so gerne gesehen von Fedora.
So weit ich das beurteilen kann ist das eher anders rum. Aber das kommt auch wieder auf die Sichtweise an -- klar gibt es einige die livna nicht mögen.
Es läßt sich nicht jedem rechtmachen. Die Auswahl an Extrapaketen bei livna ist beschränkt, teils auch auf rechtliche Bedenken zurückzuführen. Bei der Qualitätskontrolle könnte rigoroser vorgegangen werden. faad2 und mplayer mal als Beispiel genommen. Einige andere Repositories nehmen einfach eine neuere Version, egal ob dies einigen Nutzern Probleme bereitet. Es ist ein ewiges Abwägen zwischen dem Drang, Updates zu veröffentlichen, die ggf. Bugs zu beheben, und Rückwärtsbewegung durch Einführung neuer Bugs, die Nutzer betreffen, welche vorher keine Probleme hatten.
livna ersetzt dir auf jeden fall keine Pakete aus core -- dag, atrpms und kde-redhat machen das iirc.
Wie jemand kürzlich (auf fedora-list oder fedora-test-list?) treffend schrieb, ist die Philosophie von kde-redhat und atrpms als "fork" von Fedora Core zu verstehen und fährt somit auf einem anderen Gleis, als Fedora Extras, rpm.livna.org oder auch freshrpms.net/rpmforge.
Sofern ich rpmforge richtig verstehe, und "dag" beinhaltet ja ".rf" Pakete der vier (?) rpmforge Entwickler, wollen sie weiter davon abkommen, Pakete aus Fedora Core zu ersetzen. Das läßt sich aber grundsätzlich nicht in allen Fällen vermeiden. Z.B. nicht, wenn Plugin Pakete nicht möglich sind und ein Programm durch eine Version mit erweiterten Features ausgetauscht werden müßte.
Die KDE-Repositories hab ich ja von der freshrpms Seite, könnte mich aber auch täuschen. Das sind zumindest mal die Einträge in /etc/apt/sources.list: ## kde-redhat repository(s) for RedHat/Fedora RHREL rpm http://apt.kde-redhat.org/apt kde-redhat/fedora/2/i386 stable rpm http://apt.kde-redhat.org/apt kde-redhat/all stable
Ahh, da kommt das neuere vorbis her.
*mmh*
Meiner Ansicht nach sollten Newbies ihre Finger von kde-redhat lassen, so verlockend ein anders compiliertes und ggf. neueres KDE auch sein mag. Ich behaupte nicht, daß die Compilierungsprobleme in diesem Thread von kde-redhat abhängen. Es ist aber ein weiteres Mal bezeichnend, wie sich jemand durch so ein Repository von Fedora Core entfernt hat.
Am Do, den 31.03.2005 schrieb Michael Schwendt um 13:10:
Und wenn ein Newbie doch hinter die Kulissen schauen und Selbstcompilierung in Angriff nehmen möchte, sollte dies mit größter Vorsicht und Sorgfalt bei der Planung und Ausführung ablaufen. Als Grundgerüst dazu bieten sich die über 1600 Pakete aus Fedora Core an, die zweifelsohne zusammen funktionieren. Nicht erst Fragen stellen, nachdem Pakete ausgetauscht, entfernt oder Paketinhalte überschrieben wurden.
Aber woher will man wissen, OB tatsächlich was schiefläuft? Wenn ich eins bei Linux gelernt habe, dann ist es, dass kleine Veränderungen, die man als Newbie z.B.garnicht bemerkt, einem alles durcheinander bringen können. Man kann noch so viele Tutorials vorher lesen, es kann immer mal sein, dass irgendwas dann schief läuft und dann hat man den Salat, wie jetzt vermutlich bei mir zu sehen ist.
"Wir", d.h. die "Fedora Community", haben ein wachsendes Angebot von Paketerstellern, die es zu unterstützen gibt.
Diesem Zweck möchte ich ggf. eines Tages (sofern ich genug Wissen dafür gesammelt habe) auch mal dienen, aber das geht nicht ohne "Training".
Wenn ein per yum/apt-get aus einem Repository bezogenes Paket in seiner bestimmten Betriebssystemumgebung nicht funktioniert, gehört es zum guten Ton, diesen Fehler zu melden.
Wobei wir wieder dabei wären, wie ein Anfänger nachvollziehen soll, woran es liegt...
Es läßt sich nicht jedem rechtmachen. Die Auswahl an Extrapaketen bei livna ist beschränkt, teils auch auf rechtliche Bedenken zurückzuführen. Bei der Qualitätskontrolle könnte rigoroser vorgegangen werden. faad2 und mplayer mal als Beispiel genommen. Einige andere Repositories nehmen einfach eine neuere Version, egal ob dies einigen Nutzern Probleme bereitet. Es ist ein ewiges Abwägen zwischen dem Drang, Updates zu veröffentlichen, die ggf. Bugs zu beheben, und Rückwärtsbewegung durch Einführung neuer Bugs, die Nutzer betreffen, welche vorher keine Probleme hatten.
livna ersetzt dir auf jeden fall keine Pakete aus core -- dag, atrpms und kde-redhat machen das iirc.
Den Eindruck hatte ich beim lesen verschiedener Anleitungen bzgl. KDE per apt nämlich gehabt und bin dann davon ausgegangen, dass es klappen würde. Mein Fehler.., nur woher soll man das vorher wissen, wenn sogar auf kde.org Anleitungen dafür stehen... (Was nicht umbedingt ein Kriterium ist)
Meiner Ansicht nach sollten Newbies ihre Finger von kde-redhat lassen, so verlockend ein anders compiliertes und ggf. neueres KDE auch sein mag. Ich behaupte nicht, daß die Compilierungsprobleme in diesem Thread von kde-redhat abhängen. Es ist aber ein weiteres Mal bezeichnend, wie sich jemand durch so ein Repository von Fedora Core entfernt hat.
Mein Problem ist, dass ich es bisher noch nie geschafft habe, GNOME und KDE parallel zu installieren, die Installation ist bei anaconda IMMER festgefahren. Darum wollte ich diesesmal den Weg gehen nur GNOME zu installieren und dann das aktuellste KDE. Ich hatte mich auch schon mit Konstruct versucht, nur leider ohne Erfolg.
Und dann bleibt die Frage, woher soll man dann die Programme kriegen?
Ausserdem ist es hier so, dass das Problem auf einer anderen Ebene als in den meisten mit bekannten Fällen liegt. Denn hier ist scheinbar dass Problem, dass beim Linken Probleme auftreten, meist sind es zunächst fehlende Abhängigkeiten. Um dies zu vermeiden hab ich diesmal im Voraus versucht alle Bibliotheken/Header Dateien, die während dem kompilieren benötigt werden per apt zu installieren, was dann wohl offenbar die ganze Unordnung erst vursacht hat.
Gruß
Cedric Laczny
P.S. Ich hab mein Problem an die transcode user List geschickt, bisher leider noch keine Antwort. Oder hätt's eher an die transcode-devel List gehen sollen?
On Thu, 31 Mar 2005 13:35:59 +0200, Cedric Laczny wrote:
Und wenn ein Newbie doch hinter die Kulissen schauen und Selbstcompilierung in Angriff nehmen möchte, sollte dies mit größter Vorsicht und Sorgfalt bei der Planung und Ausführung ablaufen. Als Grundgerüst dazu bieten sich die über 1600 Pakete aus Fedora Core an, die zweifelsohne zusammen funktionieren. Nicht erst Fragen stellen, nachdem Pakete ausgetauscht, entfernt oder Paketinhalte überschrieben wurden.
Aber woher will man wissen, OB tatsächlich was schiefläuft?
Durch Trockenübungen und vorherige Fragestellungen dazu auf Mailing-Listen.
Erstens, nicht erste Schritte mit "root" ausführen, sondern mit Deinem normalen Nutzer Account. Der kann bei "make install" keinen Schaden anrichten. Aber Du kannst lesen, was geschehen würde. Zweitens, Einsatz von ./configure --prefix=/pfad um ggf. nicht Dein System zu überschreiben. In allen Fällen sammelst Du die volle Ein- und Ausgabe, die dokumentiert, was Du unternommen hast und was wohin installiert wurde. Du liest diese Ausgabe jeweils gründlich um zu verstehen, wonach z.B. "configure" im Detail sucht und was es findet.
Wenn ich eins bei Linux gelernt habe, dann ist es, dass kleine Veränderungen, die man als Newbie z.B.garnicht bemerkt, einem alles durcheinander bringen können. Man kann noch so viele Tutorials vorher lesen, es kann immer mal sein, dass irgendwas dann schief läuft und dann hat man den Salat, wie jetzt vermutlich bei mir zu sehen ist.
Naja, kde-redhat Installation ist keine "kleine Veränderung", sondern ein ziemlicher Einschnitt.
"Wir", d.h. die "Fedora Community", haben ein wachsendes Angebot von Paketerstellern, die es zu unterstützen gibt.
Diesem Zweck möchte ich ggf. eines Tages (sofern ich genug Wissen dafür gesammelt habe) auch mal dienen, aber das geht nicht ohne "Training".
Doch, mit Bug Reports. Du hattest Laufzeitfehler bei Transcode und Verwendung eines vorcompilierten Paketes. Dann melde die bitte.
Wenn ein per yum/apt-get aus einem Repository bezogenes Paket in seiner bestimmten Betriebssystemumgebung nicht funktioniert, gehört es zum guten Ton, diesen Fehler zu melden.
Wobei wir wieder dabei wären, wie ein Anfänger nachvollziehen soll, woran es liegt...
Muß er das? Schritt-für-Schritt Anleitung, wie ein Fehler zu reproduzieren ist, reicht für den Anfang.
Wenn Dein System natürlich nicht mehr Fedora Core 2 ist, sondern eine Mixtur aus FC2 und vielen ersetzten Paketen, können Seiteneffekte auftreten.
Mein Problem ist, dass ich es bisher noch nie geschafft habe, GNOME und KDE parallel zu installieren,
???
In Fedora Core (und vorher Red Hat Linux) sind GNOME und KDE als parallel installierbar enthalten.
Was in aller Welt probierst Du?
die Installation ist bei anaconda IMMER festgefahren.
Was heißt das?
Darum wollte ich diesesmal den Weg gehen nur GNOME zu installieren und dann das aktuellste KDE.
? Selbst nach Installation von Fedora Core per CD ließe sich KDE/GNOME per graphischem Tool von CD nachinstallieren.
Ich hatte mich auch schon mit Konstruct versucht, nur leider ohne Erfolg.
Nicht der naheliegende Weg.
Und dann bleibt die Frage, woher soll man dann die Programme kriegen?
Welche?
Ausserdem ist es hier so, dass das Problem auf einer anderen Ebene als in den meisten mit bekannten Fällen liegt. Denn hier ist scheinbar dass Problem, dass beim Linken Probleme auftreten, meist sind es zunächst fehlende Abhängigkeiten. Um dies zu vermeiden hab ich diesmal im Voraus versucht alle Bibliotheken/Header Dateien, die während dem kompilieren benötigt werden per apt zu installieren, was dann wohl offenbar die ganze Unordnung erst vursacht hat.
Seh ich nicht so. Du hattest anfangs sogar Probleme mit LAME, die Du dann durch Aufruf von "autoconf" zu beheben meintest. Bereits das wirkte sehr merkwürdig. Wenn ein LAME Test enthalten ist, verschwindet der nicht durch Aufruf von autoconf, einem Tool für Entwickler.
Am Do, den 31.03.2005 schrieb Michael Schwendt um 13:59:
Durch Trockenübungen und vorherige Fragestellungen dazu auf Mailing-Listen.
Da vergehen entsprechend Tage bis ich durch die ganzen Dokus durch bin. Ob sie dann für meinen Fall passen, weiss ich nunmal erst wenn ich's auch ausprobiert habe. Womit wir zum nächsten Punkt käme. s.u
Erstens, nicht erste Schritte mit "root" ausführen, sondern mit Deinem normalen Nutzer Account. Der kann bei "make install" keinen Schaden anrichten. Aber Du kannst lesen, was geschehen würde. Zweitens, Einsatz von ./configure --prefix=/pfad um ggf. nicht Dein System zu überschreiben. In allen Fällen sammelst Du die volle Ein- und Ausgabe, die dokumentiert, was Du unternommen hast und was wohin installiert wurde. Du liest diese Ausgabe jeweils gründlich um zu verstehen, wonach z.B. "configure" im Detail sucht und was es findet.
Nunja, ./configure und make mache ich nie als root, erst wenn die durchgelaufen sind, kommt checkinstall und erstellt ZUNÄCHST ein RPM. Für mich war bisher dann die Sache erledigt, da RPM ja auf die Abhängigkeiten "achtet" (oder dann halt auch nicht...). Dann wird erst das RPM installiert und somit dann die Dateien an den entsprechenden Ort gebracht.
Wenn ich eins bei Linux gelernt habe, dann ist es, dass kleine Veränderungen, die man als Newbie z.B.garnicht bemerkt, einem alles durcheinander bringen können. Man kann noch so viele Tutorials vorher lesen, es kann immer mal sein, dass irgendwas dann schief läuft und dann hat man den Salat, wie jetzt vermutlich bei mir zu sehen ist.
Naja, kde-redhat Installation ist keine "kleine Veränderung", sondern ein ziemlicher Einschnitt.
"Wir", d.h. die "Fedora Community", haben ein wachsendes Angebot von Paketerstellern, die es zu unterstützen gibt.
Diesem Zweck möchte ich ggf. eines Tages (sofern ich genug Wissen dafür gesammelt habe) auch mal dienen, aber das geht nicht ohne "Training".
Doch, mit Bug Reports. Du hattest Laufzeitfehler bei Transcode und Verwendung eines vorcompilierten Paketes. Dann melde die bitte.
Daran hatte ich unglücklicherweise nicht gedacht, da ich meistens davon ausgehe, dass ich der Verursacher des Problems bin, weil ich irgendwas falsch eingestellt habe o.ä.
Wenn ein per yum/apt-get aus einem Repository bezogenes Paket in seiner bestimmten Betriebssystemumgebung nicht funktioniert, gehört es zum guten Ton, diesen Fehler zu melden.
Wobei wir wieder dabei wären, wie ein Anfänger nachvollziehen soll, woran es liegt...
Muß er das? Schritt-für-Schritt Anleitung, wie ein Fehler zu reproduzieren ist, reicht für den Anfang.
Nunja, irgendwie ärgert es einen schon, wenn man versucht ein Paket zu installieren und es will partout nicht... Dann probiert man halt und eh man sich's versieht ist es schon zu spät. Hoffentlich schaffe ich es in Zukunft mich zurück zu halten :)
Wenn Dein System natürlich nicht mehr Fedora Core 2 ist, sondern eine Mixtur aus FC2 und vielen ersetzten Paketen, können Seiteneffekte auftreten.
Das habe ich nun auch gemerkt, war mir vorher nicht bewusst, dass es trotz RPM und "für FC2 erstellt" dazu kommen kann.
Mein Problem ist, dass ich es bisher noch nie geschafft habe, GNOME und KDE parallel zu installieren,
???
In Fedora Core (und vorher Red Hat Linux) sind GNOME und KDE als parallel installierbar enthalten.
So ist es wohl in fast allen Fällen, bei mir aber nicht. (Ich hab's mehr als einmal probiert und es gibt bei der Auswahl in Anaconda ja nicht SO viele Fehler zu machen...)
Was in aller Welt probierst Du?
Ich hab noch keine Entscheidung getroffen, ob ich KDE oder GNOME besser finde, deswegen will ich beides drauf haben.
die Installation ist bei anaconda IMMER festgefahren.
Was heißt das?
Das heisst, dass mein System nicht mehr reagiert, ich den PC Reseten musste, jedes Mal.
Darum wollte ich diesesmal den Weg gehen nur GNOME zu installieren und dann das aktuellste KDE.
? Selbst nach Installation von Fedora Core per CD ließe sich KDE/GNOME per graphischem Tool von CD nachinstallieren.
Dann hätte ich aber das alte KDE von FC2.
Ich hatte mich auch schon mit Konstruct versucht, nur leider ohne Erfolg.
Nicht der naheliegende Weg.
Der Ehrgeiz trieb mich aber dazu :)
Und dann bleibt die Frage, woher soll man dann die Programme kriegen?
Welche?
Wenn man zunächst sich nur auf RPMs von core beschränkt, wo nicht alle möglichen Pakete enthalten sein können.
Seh ich nicht so. Du hattest anfangs sogar Probleme mit LAME, die Du dann durch Aufruf von "autoconf" zu beheben meintest. Bereits das wirkte sehr merkwürdig. Wenn ein LAME Test enthalten ist, verschwindet der nicht durch Aufruf von autoconf, einem Tool für Entwickler.
Wenn man aber das configure-Skript geändert hat und versehentlich irgendwo einen Buchstaben eingefügt hat, ohne es zu merken, dann kann das schief laufen :)
Ein ./configure mit allen gewünschten Optionen "from scratch" (also das Alte gelöscht und ganz neu entpackt, klappte ja auch, dann.
Gruß
Cedric Laczny
On Thu, 31 Mar 2005 14:22:46 +0200, Cedric Laczny wrote:
Mein Problem ist, dass ich es bisher noch nie geschafft habe, GNOME und KDE parallel zu installieren,
???
In Fedora Core (und vorher Red Hat Linux) sind GNOME und KDE als parallel installierbar enthalten.
So ist es wohl in fast allen Fällen, bei mir aber nicht. (Ich hab's mehr als einmal probiert und es gibt bei der Auswahl in Anaconda ja nicht SO viele Fehler zu machen...)
Was in aller Welt probierst Du?
Ich hab noch keine Entscheidung getroffen, ob ich KDE oder GNOME besser finde, deswegen will ich beides drauf haben.
die Installation ist bei anaconda IMMER festgefahren.
Was heißt das?
Das heisst, dass mein System nicht mehr reagiert, ich den PC Reseten musste, jedes Mal.
Das ist ganz klar kein Problem, das mit KDE/GNOME Auswahl zusammenhängt, sondern läßt auf Hardwareprobleme schließen.
Prüfe wenigstens, ob Du noch mit Strg+Alt+F2 etc. auf eine der Textkonsolen schalten kannst.
Darum wollte ich diesesmal den Weg gehen nur GNOME zu installieren und dann das aktuellste KDE.
? Selbst nach Installation von Fedora Core per CD ließe sich KDE/GNOME per graphischem Tool von CD nachinstallieren.
Dann hätte ich aber das alte KDE von FC2.
Und das ist gut so. Ein neueres gibt es in FC3, und ein noch neueres in FC4 Test2 nächste Woche.
Seh ich nicht so. Du hattest anfangs sogar Probleme mit LAME, die Du dann durch Aufruf von "autoconf" zu beheben meintest. Bereits das wirkte sehr merkwürdig. Wenn ein LAME Test enthalten ist, verschwindet der nicht durch Aufruf von autoconf, einem Tool für Entwickler.
Wenn man aber das configure-Skript geändert hat und versehentlich irgendwo einen Buchstaben eingefügt hat, ohne es zu merken, dann kann das schief laufen :)
Wie ich schonmal schrieb, was treibst Du da? ;) Wenn für eine Mailing Liste nicht nachvollziehbar ist, was bei Dir abläuft, ist ein Thema von vornherein eine Sackgasse.
Am Do, den 31.03.2005 schrieb Michael Schwendt um 14:32:
Das ist ganz klar kein Problem, das mit KDE/GNOME Auswahl zusammenhängt, sondern läßt auf Hardwareprobleme schließen.
Aber wieso funktioniert die Installation von KDE ODER GNOME ohne Probleme dann? Ich geb zu, ich hab ein Software-Raid (trotz onboard RAID Controller von Silicon Image). Dass es da HardwareProbleme geben kann verstehe ich, darum musste ich ja auch auf die Lösung, KDE nachträglich zu installieren ausweichen. (FC2 war damals die einzige Distribution die ICH zum laufen bringen konnte mit der Hardware, ausserdem hat FC2 sonst auch alle meine HW ordentlich erkannt, darum wollte ich ihm schon treu bleibe :D)
Prüfe wenigstens, ob Du noch mit Strg+Alt+F2 etc. auf eine der Textkonsolen schalten kannst.
Bei nächsten Mal werd ich das tun, Danke für den Tipp
Und das ist gut so. Ein neueres gibt es in FC3, und ein noch neueres in FC4 Test2 nächste Woche.
Ich bin allerdings kein Fan von FC3. Wenn ich direkt nach der Installation schon den ersten Patch für Multihead bei der ATI Radeon 9200 drauf hauen muss, obwohl es bei FC2 ja ohne Probleme ging, dann ist das schon unpraktisch. Ausserdem hat der HAL-Dämon, oder UDEV plötzlich nur noch gesponnen. Für Leute die oft USB Devices an und abschliessen, mögen die gut sein, aber ich hab EINEN USB-Stick und EINE externe Platte, da ist es mir egal, wieviele Einträge in /dev/ rumlungern, einmnal konfiguriert und fertig :) Vielleicht wird's mit FC4 ja besser.
Wie ich schonmal schrieb, was treibst Du da? ;) Wenn für eine Mailing Liste nicht nachvollziehbar ist, was bei Dir abläuft, ist ein Thema von vornherein eine Sackgasse.
Das ist klar :). Aber das Problem mit configure liess sich ja beheben, scheinbar weiss auf der transcode ML noch nicht mal jemand was mit meinem Problem anzufangen...
Gruß
Cedric Laczny
Am Donnerstag, den 31.03.2005, 14:54 +0200 schrieb Cedric Laczny:
Am Do, den 31.03.2005 schrieb Michael Schwendt um 14:32:
Das ist ganz klar kein Problem, das mit KDE/GNOME Auswahl zusammenhängt, sondern läßt auf Hardwareprobleme schließen.
Aber wieso funktioniert die Installation von KDE ODER GNOME ohne Probleme dann?
Herr Doktor Kfz, ich hab mein Auto mehrfach 30 Minuten mit Vollgas betrieben und alles ist gut gegangen. Aber als ich es 45 Minuten mit Vollgas betrieben habe ist der Motor explodiert. Woran liegt das?
(Oder um wie viele Minuten verlängert sich die Installation mit beiden Desktop Oberflächen? Egal.)
Soweit zu meiner sarkastischen Seite. Sorry. Ja, ich bin auch fest davon überzeugt das es ein Hardware-Problem ist. Bin selbst schon einmal in genau solch ein Problem (und mehrfach in ähnliche) gerannt. Wenn es ein Fedora-Problem ist sollte die Installation zudem jedes mal am gleichen Punkt stocken.
CU thl
Cedric Laczny schrieb:
Nunja, ./configure und make mache ich nie als root, erst wenn die durchgelaufen sind, kommt checkinstall und erstellt ZUNÄCHST ein RPM. Für mich war bisher dann die Sache erledigt, da RPM ja auf die Abhängigkeiten "achtet" (oder dann halt auch nicht...). Dann wird erst das RPM installiert und somit dann die Dateien an den entsprechenden Ort gebracht. Gruß Cedric Laczny
Hallo,
checkinstall beobachtet bei der Installation "make install" und baut daraus ein rpm. Die Dateien werden dabei aber schon installiert. Wenn Du dann das erstellte rpm einspielst, werden diese Dateien nochmals überschrieben. Nun aber weiß rpm davon, beachtet alle Abhängigkeiten und danach lässt sich das rpm auch wieder restlos entfernen, so man will.
Die sicherste, aber auch aufwändigste, Methode ist natürlich das Erstellen mittels rpmbuild. Und das geht komplett als User nach dem setzen einiger Variablen.
Bye Mario
On Thu, Mar 31, 2005 at 01:10:16PM +0200, Michael Schwendt wrote:
Wie jemand kürzlich (auf fedora-list oder fedora-test-list?) treffend schrieb, ist die Philosophie von kde-redhat und atrpms als "fork" von Fedora Core zu verstehen
Woher dichtest Du Dir solchen Unsinn zusammen?
und fährt somit auf einem anderen Gleis, als Fedora Extras, rpm.livna.org oder auch freshrpms.net/rpmforge.
Sorry Michael, aber Deine Mails schlagen immer wieder FUD-Alarm aus.
Am Do, den 31.03.2005 schrieb Cedric Laczny um 9:05:
Am 31.03.2005 um 03:05 schrieb Alexander Dalloz:
Darf ich mal kräftig "aua!" sagen? Warum meinen nur so viele User, sie könnten so mir nichts dir nichts irgendwelche RPMs problem- und risikolos auf ihr System knallen, die sie auf irgendwelchen RPM Suchmaschinen / Referenzierungsseiten entdeckt haben?
Darf ich mal fragen, was eine derartig unnötige Aussage soll? Von einem doch stark vertetenen Ratgeber in dieser ML hätte ich einen derartigen Kommentar nicht erwartet, sondern lieber mal einen konstruktiven Beitrag zum eigentlichen Problem.
Hallo Cedric!
Sorry, dass ich erst jetzt zu einer Entgegnung auf deine Beschwerde und Ermahung komme. Inzwischen gab es ja schon einen sachlichen "Schlagabtausch". Mein metaphorisches "aua!" war mitnichten sarkastisch gemeint. Es war ein eher gequältes Seufzen, und gewiss kein Grinsen mit Schadenfreude und Überheblichkeit. Wie Thorsten bereits erwiderte, es ging mir um ein Problem, dass man leider allzu häufig antrifft. Es sind wirklich mehr als genug Probleme hausgemacht, in dem Sinne, dass Fremdpakete - also passgenau in die Distribution eingebaute Pakete/RPMs - eingespielt werden, und dann an i.d.R. anderer Stelle "merkwürdige" Probleme auftreten. Genau so in diesem Fall: Erst gibt es ein Hin und Her mit Schilderungen über ein auftretendes Problem, Nachfragen und Erklärungsversuche, um dann nach einem Dutzend Mails zu hören, dass sich da im System Pakete befinden, die die eigentlichen, zum Release der Distribution gehörenden Pakete ersetzt haben. Glaube mir, ich habe nicht selten lesen müssen, dass User Mandrake oder SuSE RPMs in ihr Red Hat Linux reingewürgt haben ("wenn es nicht will, dann mit --force oder --nodeps - ich brauche oder will das ja"). Vielleicht ist RPM auch in mancherlei Hinsicht zu gutmütig. Ich glaube das dpkg von Debian weigert sich etwas hartnäckiger, oder es liegt einfach an der Tatsache, dass dpkg mehr oder weniger auf Debian beschränkt ist, während es doch mehr als eine RPM basierte Distribution mit deutlich unterschiedlichen RPMs (und eigenen Makros) gibt.
Tut mir Leid, ich kann mich noch nicht Linux-Guru nennen und wenn ich ein RPM finde, das für FC2 sein soll und es sich installieren läßt bin ich erstmal zufrieden.
Wem vertraust du dabei, dass das RPM für FC2 sein soll? Vielleicht zeigst du uns zur Demonstration einfach mal die URL und das genaue Paket? rpmseek.com ist ja keine Fedora spezifische RPM Suchmaschine wie z.b. der FedoraTracker www.fedoratracker.org.
Die User machen das vermutlich, weil sie sich auf das Paketmanagment vom RPM verlassen und nunmal bei jedem Programm und jeder Distribution die Installation anders verläuft.
Weil etwas wie eine Schraube aussieht und ich auch einen Dreher habe, der für den Kopf der Schraube passt, heißt das noch lange nicht, dass die Schraube in das anvisierte Gewinde passt/gehört. (Auch wenn dieser Vergleich ein wenig hinkt.)
Woher soll man denn bei jedem Paket wissen, das zudem noch von apt-get automatisch installiert wird, ob da jetzt alles 100% auf mein System passt? Ich für meinen Teil bin froh, dass ich schon manche Pakete
Zum einen sollte man sehr genau wissen, welche Quellen für Pakete man in seinem Tool wie apt-rpm, yum oder up2date setzt. Das schließt Zuverlässigkeit des Repository Managers ein wie auch die QA des Repositories. Um das zu evaluieren kann man z.B. im Vorfeld recherchieren und Feedback anderer User ermitteln.
selbst kompilieren konnte und daraus RPMS erstellen konnte, da Installation von Software unter Linux nunmal noch ein relativ aufwendiger Akt im vergleich zu anderen OS wie Windows oder Mac OS X ist. Ich für meinen Teil bin definitiv eher der Anwendertyp und
Aha, wie viel und welche Software hast du denn jemals auf Windows® Plattformen selbst kompiliert und ordnungsgemäß ins System integriert? Der übliche Triple-Schritt "./configure, make, make install" mag zwar verlockend einfach anmuten, erfordert jedoch schon einiges an Wissen. Und das meine ich gewiss nicht Hochnäsig. Auch mir fehlt genügend Wissen, vielleicht bin ich nur weitaus vorsichtiger in Bereichen, wo ich nur sehr lückenhaft Bescheid weiß. Möglicherweise hast du auch schon mal davon gehört, dass es Rechnerumgebungen gibt, wo den Administratoren ausdrücklich verboten ist, Software zu installieren bzw. eigenmächtig Updates einzuspielen. Dort findet erst ein längerer, ausgiebiger Evalutionsprozess in expliziten Testumgebungen statt, bevor eine Software dann freigegeben wird. Um nur ein Beispiel aus der nicht-Linux Welt zu nennen: es gibt etliche Firmen, wo das Windows XP® SP2 nicht flächendeckend aufgespielt wird, weil die Evaluation Probleme aufgezeigt hat, die schwerer wiegen als jene, die ohne Service Pack Patches existieren.
Cedric Laczny
Alexander
Am Do, den 31.03.2005 schrieb Cedric Laczny um 9:05:
YES! Wollt ihr wissen, woran es lag? :) Es lag daran, dass der libavcodec dynamisch gelinkt werden musste. Sowas hatte ich vorher auch schon gefunden, aber nur für ffmpeg. Aber der libavcodec kommt von avifile. Ich hatte mich gewundert, warum ffmpeg mit --enable-shared beim anschliessendem installieren per RPM fehlende Abhängigkeiten bemängelte, eben libavcodec, da ich dachte, ffmpeg würd den mitbringen. avifile mit der Option neu kompiliert und transcode schnurrt durch wie ein Kätzchen. Sogar mit Ogg/Vorbis Support.
Danke an alle die versucht haben Licht in's Dunkel zu bringen.
Gruß
Cedric Laczny
Am Freitag, 1. April 2005 12:01 schrieb Cedric Laczny:
Am Do, den 31.03.2005 schrieb Cedric Laczny um 9:05:
YES! Wollt ihr wissen, woran es lag? :) Es lag daran, dass der libavcodec dynamisch gelinkt werden musste. ...
Hallo Cedric,
ich habe den Thread mit Interesse verfolgt, weil ich auch schon Probleme mit Transcode hatte und gezwungen bin aus Quellen zu installieren, die problematisch sind. Bei einem Multimedia-Rechner hat man aber nicht viel Wahl, wenn man nicht alles selber kompiliert. Zur Freude ging es mit den kipi-plugins inklusive automatischem 3.4-Update gut. Allerdings macht mplayer Probleme, xine aber nicht.
Hast du zufällig mplayer installiert und läuft der bei dir?
Al
Am Fr, den 01.04.2005 schrieb Al Bogner um 15:58:
Hallo Cedric,
ich habe den Thread mit Interesse verfolgt, weil ich auch schon Probleme mit Transcode hatte und gezwungen bin aus Quellen zu installieren, die problematisch sind. Bei einem Multimedia-Rechner hat man aber nicht viel Wahl, wenn man nicht alles selber kompiliert. Zur Freude ging es mit den kipi-plugins inklusive automatischem 3.4-Update gut. Allerdings macht mplayer Probleme, xine aber nicht.
Hast du zufällig mplayer installiert und läuft der bei dir?
Ja, mit dem hab ich keine Probleme, den hab ich aber selbst kompiliert gehabt. Vielleicht liegt es ja daran. Ich hab ausserdem noch Kaffeine und gxine als Media-Player, funktionieren alle zuverlässig.
Was sind denn kipi-plugins? Mit automatischem 3.4-Update meinst Du KDE?
Gruß
Cedric Laczny
Am Freitag, 1. April 2005 16:27 schrieb Cedric Laczny:
Hast du zufällig mplayer installiert und läuft der bei dir?
Ja, mit dem hab ich keine Probleme, den hab ich aber selbst kompiliert gehabt.
Ok, das ist was anderes. Ich will mich damit zur Zeit nicht rumärgern, xine-basierte Player wie Kaffeine funktionieren ja. Die Mplayer-Fehlermeldung poste ich bei Interesse, müsste dazu aber zu einem anderen Rechner.
Was sind denn kipi-plugins? Mit automatischem 3.4-Update meinst Du KDE?
http://extragear.kde.org/apps/kipi/
Ja ich meinte KDE 3.4. Mich interessiert speziell das Erstellen eines Films von Fotos mit dem Digikam-Plugin. Heute kam ein Update rein, das ich noch nicht getestet habe. Gestern gab es noch Probleme, wenn man Übergänge definierte. Vgl. http://bugs.kde.org/show_bug.cgi?id=101110
Al
Am Fr, den 01.04.2005 schrieb Al Bogner um 22:03:
Ok, das ist was anderes. Ich will mich damit zur Zeit nicht rumärgern, xine-basierte Player wie Kaffeine funktionieren ja. Die Mplayer-Fehlermeldung poste ich bei Interesse, müsste dazu aber zu einem anderen Rechner.
Gerne, würde mich interessieren, vielleicht kenne ich sie ja :) Aber ich hatte keine Probleme mit dem Übersetzen der MPlayer Quellen. Das ging, wenn ich mich recht erinnere recht flott. Ich hab eben aber einfach mal meinem MPlayer deinstalliert und per apt-get einen anderen dann installiert, gab keinerlei Probleme.
Gruß
Cedric Laczny
de-users@lists.fedoraproject.org
-
Al Bogner -
Alexander Dalloz -
Axel Thimm -
Cedric Laczny -
Mario Mueller -
Michael Schwendt -
Thorsten Leemhuis