Ich habs schon ein paarmal versucht, KDE selbst zu kompilieren und bin bisher jedesmal an irgendwelchen Abhängigkeiten gescheitert. Ich versuchs glech heut abend mal, vielleicht klappts mit deiner Anleitung.
Wobei ich nicht unbedingt den /opt/kde3 Pfad benutzen würde, daß könnte später mit rpm's konflikten. besser /opt/kde3-cvs oder so ... gleiches gilt für den QT Pfad.
Wenn man es selber kompiliert, braucht man ja keine rpms. Ich habe _gerade_ /opt/kde3 gewählt, weil man dann rpms von KDE-Programmen hinzufügen kann. Aber auch diese kann man dann relativ einfach hinzukompilieren :-)
Stellt sich nur die Frage ob das für KDE wirklich so nötig ist ... ich fand das immer einfach zu kompilieren. Aber für gnome wäre sowas mehr als Hilfreich! Dieses System ist doch nur ein einziges großes Chaos aus Bibliotheken und Abhängigkeiten. Ich habe es nie geschaffte das sauber von Grund auf zu kompilieren ...
Ich wollte GNOME zum Ausprobieren auch mal kompilieren, aber die Anleitung im Linux-Magazin hat so viele Schwierigkeiten erwähnt, daß ich es sein gelassen habe...
Ich hatte mit -march=i686 keine Probleme, im Gegensatz zu --enable-final, damit ließ sich ktexmaker nicht kompilieren. --enable-final also ohne Gewähr, mit genug RAM geht das Kompilieren damit sogar schneller!
Weißt Du genau daß --disable-debug einen Unterschied macht? Ich dachte, das wäre default.
Ich verstehe das so, daß man mit --disable-debug gar keine backtraces machen kann und auch keine Ausgabe auf die Konsole bekommt. Versuch macht hier kluch. Mit --enable-debug bekommt man sehr viele debug-Infos und Dateigröße steigt beträchtlich. Das weiß ich ;-)
Keins von beidem ist wahrscheinlich ein Mittelding, das kaum langsamer ist als --disable-debug.
support (so notwendig) arts kdelib kdebase kde-(weitere Pakete)
im Paket kdesdk finden sich einige interessante Build-Skripte, die z.B. ein KDE direkt in ein CVS installieren. Empfehlung für ein selbstgebautes KDE: Benutzt qt-copy aus dem KDE-CVS. Es handelt sich um ein Qt-(pre)release+Bugfix
Was sonst noch... Ahh - das aktuelle KDevelop hat den CVS-Tag: KDE_2_2_BRANCH - auch für KDE3!!
Viel Spass beim Basteln, es lohnt sich. Achtet auf die ./configure-Optionen und -Logs!
P.S.: Und werft ein Auge auf die con configure erstellte config.log - manchmal macht configure nämlich einen ziemlichen Müll (bei mir zum Beispiel weigert es sich den OggVorbis Support zu finden *grübel*)
KDE ist wirklich ziemlich einfach zu bauen im Grunde reichen ja arts (beim cvs) kdelibs und kdebase aus. Weil das ganze so simple ist kann man das sogar hervorragend automatisieren z.b. über ein kleines Shellscript.
Beim gcc-3.0.x gibt es zumdindest eine Option für die Athlon-CPU's "-march=athlon". Zwischen dem Athlon und dem XP gibts ja zudem keine so grossen Unterschiede als das es dort extra Optimierungen vom gcc geben müsste. Im Grunde besitzt der Palomino-Kern ja nur weitaus bessere Algorithen zur Sprungvorhersage (und der XP basiert ja auf dem Palomino-Prozessorkern).
Das mit dem Shell-Skript habe ich weggelassen, weil da jeder seine Vorlieben hat, wie sich das bei Fehlern verhalten soll. Wenn man Shell-Skripte nicht beherrscht, benutzt man IMHO auch besser keines, das man nicht versteht. Natürlich benutze ich eines
Von Thorsten Schnebeck am Mo, 18. März 2002 um 12:19 #
Naja, das Howto ist zwar ein wenig schwammig aber er hat sich die Mühe gemacht, es zu versuchen (und nicht nur gemotzt ;-)
Hinweise Teil2: libxml, libxslt sind u.a. in kdesupport, wenn man es noch nicht hat, kann man kdesupport installieren ansonsten ist ein Update der Distri-Pakete durchzuführen. Man braucht natürlich immer die Developer-Version.
openssl-0.9.6c funktioniert prima bei mir ;-) Problem ist, es gibt Leute die einen Symbolkonflikt mit der glibc-2.2.5 haben, andere haben ihn wiederum nicht. Deshalb gibts die Empfehlung 0.9.6b zu verwenden.
object-prelink ebenso wie --enable-fast-malloc=full in den libs gilt als experimentell! --disable-debug ist eine zweischneidige Sache, ich bitte all diejenigen, die eine halbwegs schnelle Maschine (>700 MHz) haben, die Debug-Symbole drin zu lassen. Es ist ein 3._0_-Release und es wird bestimmt der eine oder andere Fehler auftauchen und da helfen die Symbole!
"Diese Anleitung erhebt nicht den Anspruch an Vollständigkeit und Fehlerfreiheit, ich hoffe jedoch, sie reicht den meisten Leuten, um KDE selber kompilieren zu können."
Lies mal http://www.kde.org/install-source.html
Natürlich ist neuer meistens besser, Ausnahmen bestätigen die Regel.
QT ist nicht Bestandteil von KDE, die rpms vom Distributor funktionieren. Notwendig ist es auf jeden Fall. Du darfst gerne eine Anleitung dafür schreiben, die kann man dann hinzulinken.
Poste mal die Adressen der anderen HOWTOS und lies die angegebenen Links.
Positiv am Kommentar: Auf Fehler und mögliche Konflikte wird hingewiesen. Dadurch wird das How-To verbessert und optimiert. Voll im Sinn von Freier Software.
Negativ: Gemecker!
Niemand ist vollkommen und kann auf alle Eventualitäten eingehen. Daher ist es gut, wenn andere sich den Text durchlesen und Hinweise geben. Dadurch wird ein Höchstgrad an Perfektion erreicht. Ob nun Software oder Literatur, für beide gilt das gleiche.
Warum muß immer jemand auf die Idee kommen, eine neues eigenes HOWTO aufzustellen wo es doch schon welche, bessere (auch auf deutsch) gibt. Irgendwann wird man müde in/an jedem neuem immer gleiche Fehler zu kritisieren/meckern.
AFAIK ist kdesupport obsolet. Es gibt auch keine Quellpakete dafür auf download.kde.org. libx... kann man ruhig nach /usr installieren und dort alte Versionen überschreiben.
Von Thorsten Schnebeck am Mo, 18. März 2002 um 12:37 #
Hi Jochen P.
Obsolet ist genau das richtige Wort! Aber es ist auch ungemein praktisch, da es die Pakete enthält die nicht Teil von KDE sind aber unbedingt benötigt werden, um es zu bauen. Da kann man sich sicher sein, dass die Versionsnummern passen.
Von Thorsten Schnebeck am Mo, 18. März 2002 um 13:17 #
Naja,
wenn du (mein Steckenpferd) KDE3 baust, wirst auch du bald feststellen, dass bei KDE die Pakete am einfachsten direkt aus dem CVS gesaugt werden ;-)
Du hast da den Vorteil, dass auch die Sourcen zur Verfügung stehen, die nicht öffentlich gepackt wurden, so gibt es seit heute KDE-3rc3 ebenso seit gestern qt-3.0.3pre5(?). Gerade wenn du deine Installation aus dem CVS machst (lässt sich ja auch wunderbar scripten!) lässt sich eine Installation simpelst einfach auf Stand bringen ohne jedes mal Megabyteweise gepackte Pakete runterladen zu müssen.
rc3 hatte ich schon am Freitag ;-P QT aus dem CVS ist mir zu lästig ;-)
Wie man sicherlich schon an den vielen Verbesserungen gemerkt hat, wollte ich die Anleitung auf das notwendigste beschränken. Wenn jemand die Quellpakete erstmal kompiliert hat, kommt je nach Lust und Laune der nächste Schritt namens Skripting, CVS, --enable-debug usw.
Erstaunlicherweise wird mit --enable-debug das System nicht linear mit den Dateigrößen langsamer, natürlich abhängig vom System.
Als newbie hätte ich keine Lust eine 1000zeilige Anleitung durchzugehen, die dafür komplett ist. Daher notwendigerweise die Unvollständigkeit.
KDE3 rulz ! Auch wenn es oft Ungereimtheiten gab, z.B. hatte ich trotz(?) schneller Verbindung die arts-Version 0.9.x und kdelibs wollte 0.9.x-1 ... Da hört es für den newbie schon auf, Spaß zu machen.
Da disable-debug default-mäßig auf no steht, werden die Pakete _mit_ Debug-Symbolen bebaut, will man das nicht muss man ausdrücklich --disable-debug eingeben. Ein --enable-debug=no funktioniert AFAIK nicht!
Und? Das wurde vor Tagen vorsorglich geändert damit es nicht wie bei rc2 vergessen wird (siehe dazugehörigen CVS Kommentar). Das Tag KDE_3_0_RELEASE steht noch immer auf Stand rc2. Es ist rc2 wenn es gepackt auf dem FTP-Server liegt _und_ (auch Erfahrung von rc2) als solches in der Mailing-Liste announct wurde.
Von Thorsten Schnebeck am Mo, 18. März 2002 um 20:42 #
Anonymous am Mo, 18 Mär 2002 um 20:16 kennt sich anscheinend gut aus. Aber war es nicht so, dass Dirk HEAD in KDE_3_0_RELEASE "umkopiert" und dieses dann RC1..X nennt? Ich dachte, dass nur öffentliche Tarballs getaggt werden? Von rc1/2 gibts ja auch kein Tag. Ich sehe ja auch keine Fixes im Release-Branch, die sind in HEAD!
Von Anonymous 20:16 am Mo, 18. März 2002 um 21:18 #
> Aber war es nicht so, dass Dirk HEAD in KDE_3_0_RELEASE "umkopiert"
Da wird nichts umkopiert, es gibt derzeit genau einen KDE 3.x-Branch (HEAD) und ein Tag KDE_3_0_RELEASE was für die einzelnen Release Candidates verschoben wird.
> Ich dachte, dass nur öffentliche Tarballs getaggt werden?
Tarballs kann man gar nicht taggen. Die werden zu den einzelnen Zeitpunkten aus dem HEAD Branch mit dem TAG KDE_3_0_RELEASE, wo es dann gerade steht, erstellt.
> Von rc1/2 gibts ja auch kein Tag. Ich sehe ja auch keine Fixes im Release-Branch, die sind in HEAD!
Es gibt keine Release-Tags und auch derzeit keinen eigenen Release-Branch (erst für KDE 3.0.x dann wieder KDE_3_0_BRANCH).
Von Thorsten Schnebeck am Mo, 18. März 2002 um 21:39 #
Jo, hab' mich etwas sehr schwammig ausgedrückt, wir meinen aber das gleiche ;-) Wesentlich würde ich sagen war dein Satz vorher:" RC3 ist raus, wenn es auf der ML verkündet wird"
Tja tut zwar nicht allzu viel zu Sache aber ich verwende nach erfolgreichem komilieren der Quellen immer das Tool checkinstall um gleich meine RPMS zur erstellen . Beziehen ist das ganze unter: http://asic-linux.com.mx/~izto/checkinstall Einfach genial das Teil und optimal zum experimentieren !! Auch wenn es jeder zweite kennt, eine Erwaehnung ist es allemal Wert ......
gibts denn nirgends rpm-Packete fuer die RC's?? Ist doch schade, wenn ne Menge Leute die Packete nicht testen koenne, weil sie nicht die Zeit oder Ressourcen haben um alles zu compilieren?!
hat jemand von euch schon xtunes ausprobiert... --> neue Programme
ich wollts mir mal reinziehen, unter debian woody. aber wenn ich es ./configure, dann bringt er mir nur:
checking for PLGetProplistWithPath in -lPropList... yes checking for libcdaudio-config... no checking for libcdaudio - version >= 0.99.0... no *** The libcdaudio-config script installed by libcdaudio could not be found *** If libcdaudio was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the LIBCDAUDIO_CONFIG environment variable to the *** full path to libcdaudio-config. ./configure: couldn't find libcdaudio: command not found checking for cdda_find_a_cdrom in -lcdda_interface... no checking for paranoia_init in -lcdda_paranoia... no Error: could not find cdparanoia.
Beim Kompilieren von KDE hatte ich noch nie Probleme. Bis Version 2.2.1 oder 2.2.0 hat auch alles wunderbar funktioniert. Nur ab Version 2.2.2 und bei allen 3er Versionen komme ich bis zum 3. Element des Splashscreens. Dann kommt eine Meldung, dass Kicker abgestürzt ist (SIG 11). Im Output steht irgendwas von DCOP Communication Error und connection refused. Ich hab schon bei google gesucht, bin aber nicht richtig fündig geworden. Vielleicht kann mir ja hier jemand helfen.
Starte auf der Konsole mal kbuildsycoca - damit wird eine Konfigurationsdatenbank von KDE neu erstellt. Wichtig sind richtige Umgebungsvariablen $KDEDIR und $KDEHOME. Evtl. hilft es, das .kde-Verzeichnis zu löschen.
Ich habs schon ein paarmal versucht, KDE selbst zu kompilieren und bin bisher jedesmal an irgendwelchen Abhängigkeiten gescheitert.
Ich versuchs glech heut abend mal, vielleicht klappts mit deiner Anleitung.
Gruß
Oli
Also nochmal:
Danke Jochen!!!
Probleme einfach posten.
Ich habe _gerade_ /opt/kde3 gewählt, weil man dann rpms von KDE-Programmen hinzufügen kann. Aber auch diese kann man dann relativ einfach hinzukompilieren :-)
ich bin zwar auch KDE Nutzer, aber eben hab ich da doch noch folgendes gesehen:
http://freshmeat.net/projects/gig/
Soll eine Anleitung sein, mit welcher man Gnome compilieren kann.
Mario
aber die Anleitung im Linux-Magazin hat so viele Schwierigkeiten erwähnt, daß ich es sein gelassen habe...
Betrifft Optimierung:
lieber CFLAGS="-O3 -march=i386 -mcpu=i686"
und CXXFLAGS="-O3 -march=i386 -mcpu=i686"
nehmen. -march=i686 bringt in 99% der Fälle keinerlei verbesserung gegenüber -mcpu=i686 aber gerade bei KDE 2.2.* mehrere Probleme!
ansonsten würde ich noch --enable-final und --disable-debug benutzen ...
sonst ist das mal ne gute Idee zumal ich sowas in deutsch noch nicht gesehen hab
--enable-final also ohne Gewähr, mit genug RAM geht das Kompilieren damit sogar schneller!
Weißt Du genau daß --disable-debug einen Unterschied macht?
Ich dachte, das wäre default.
> --enable-debug=ARG enables debug symbols (yes|no|full) default=no
> --disable-debug disables debug output and debug symbols default=no
Also --enable-debug=no und --disable-debug=no, irgendwie sehr ambiguous.
Versuch macht hier kluch.
Mit --enable-debug bekommt man sehr viele debug-Infos und Dateigröße steigt beträchtlich. Das weiß ich ;-)
Keins von beidem ist wahrscheinlich ein Mittelding, das kaum langsamer ist als --disable-debug.
Hat einer Lust, das durchzuprobieren ? :-)
KDE3 wird
- Qt-3.0.3
- autoconf 2.52
- automake 1.5
benötigen.
Reihenfolge der Pakete
support (so notwendig)
arts
kdelib
kdebase
kde-(weitere Pakete)
im Paket kdesdk finden sich einige interessante Build-Skripte, die z.B. ein KDE direkt in ein CVS installieren.
Empfehlung für ein selbstgebautes KDE: Benutzt qt-copy aus dem KDE-CVS. Es handelt sich um ein Qt-(pre)release+Bugfix
Was sonst noch...
Ahh - das aktuelle KDevelop hat den CVS-Tag:
KDE_2_2_BRANCH - auch für KDE3!!
Viel Spass beim Basteln, es lohnt sich.
Achtet auf die ./configure-Optionen und -Logs!
Have Fun!
Thorsten
... _aus_ dem CVS installieren
greetings
wolfy
P.S.: Und werft ein Auge auf die con configure erstellte config.log - manchmal macht configure nämlich einen ziemlichen Müll (bei mir zum Beispiel weigert es sich den OggVorbis Support zu finden *grübel*)
vielleicht ist es das?
Und was QT angeht: Inzwischen ist sogar 3.0.2 nicht mehr aktuell genug. Also am besten nen aktuellen Snapshot ziehen.
Heißt "nicht mehr aktuell genug", daß es sich ohne nicht kompilieren lässt?
KDE stellt schon lange entsprechende Bindings bereit!!!
Einfach die kdebindings mit intsallieren und schon kann man auch von Java aus KDE - Fenster erzeugen.
Das ist dann natürlich strenggenommen kein Java Look and feel abba det hat jedenfalls det wad du willst...
Weil das ganze so simple ist kann man das sogar hervorragend automatisieren z.b. über ein kleines Shellscript.
Zwischen dem Athlon und dem XP gibts ja zudem keine so grossen Unterschiede als das es dort extra Optimierungen vom gcc geben müsste. Im Grunde besitzt der Palomino-Kern ja nur weitaus bessere Algorithen zur Sprungvorhersage (und der XP basiert ja auf dem Palomino-Prozessorkern).
Wenn man Shell-Skripte nicht beherrscht, benutzt man IMHO auch besser keines, das man nicht versteht.
Natürlich benutze ich eines
> Für KDE 3 QT 3.0.1, für KDE 2 QT 2.3.1 (oder neuer)
Für KDE 3 Qt 3.0.3, für KDE 2 kein Qt 2.3.2.
> libxslt ist auch anzuraten
Für KDE 2.2.2 nicht nur anzuraten sondern notwendig.
> neueres automake, neueres autoconf
Siehe Kommentare von Thorsten
> für https-Verbindungen ein aktuelles openssl (>=0.9.6)
Da aber zum Beispiel kein 0.9.6c.
> Alle drei Sachen muß man in dieser Reihenfolge nacheinander erledigen: arts, kdelibs, kdebase
Was ist an dieser Stelle aus Qt geworden? Und dessen spezielle configure-Parameter?
> "--enable-objprelink" sorgt für ein bisschen mehr Geschwindigkeit
Was ist mit "--disable-debug"?
Ich habe schon bessere sprich vollständigere HOWTOs für KDE gesehen.
Hinweise Teil2:
libxml, libxslt sind u.a. in kdesupport, wenn man es noch nicht hat, kann man kdesupport installieren ansonsten ist ein Update der Distri-Pakete durchzuführen. Man braucht natürlich immer die Developer-Version.
openssl-0.9.6c funktioniert prima bei mir ;-)
Problem ist, es gibt Leute die einen Symbolkonflikt mit der glibc-2.2.5 haben, andere haben ihn wiederum nicht. Deshalb gibts die Empfehlung 0.9.6b zu verwenden.
Qt3:
CONF="-system-zlib \
-qt-gif -system-libpng -system-libjpeg -plugin-imgfmt-mng \
-no-g++-exeptions -thread -no-stl -xinerama"
BTW, schon alle ihre zlib ersetzt ;-)
object-prelink ebenso wie --enable-fast-malloc=full in den libs gilt als experimentell!
--disable-debug ist eine zweischneidige Sache, ich bitte all diejenigen, die eine halbwegs schnelle Maschine (>700 MHz) haben, die Debug-Symbole drin zu lassen. Es ist ein 3._0_-Release und es wird bestimmt der eine oder andere Fehler auftauchen und da helfen die Symbole!
Bye
Thorsten
Lies mal
http://www.kde.org/install-source.html
Natürlich ist neuer meistens besser, Ausnahmen bestätigen die Regel.
QT ist nicht Bestandteil von KDE, die rpms vom Distributor funktionieren.
Notwendig ist es auf jeden Fall.
Du darfst gerne eine Anleitung dafür schreiben, die kann man dann hinzulinken.
Poste mal die Adressen der anderen HOWTOS
und lies die angegebenen Links.
Auf Fehler und mögliche Konflikte wird hingewiesen. Dadurch wird das How-To verbessert und optimiert.
Voll im Sinn von Freier Software.
Negativ:
Gemecker!
Niemand ist vollkommen und kann auf alle Eventualitäten eingehen. Daher ist es gut, wenn andere sich den Text durchlesen und Hinweise geben. Dadurch wird ein Höchstgrad an Perfektion erreicht. Ob nun Software oder Literatur, für beide gilt das gleiche.
Warum gibt es zu ******* mehrere Bücher, wenn ******* das beste ist ?
Wieso gibt es zig Mail-Clients, wo doch ******* der beste ist ?
So schwer ist das doch wirklich nicht zu verstehen, oder?
Es gibt auch keine Quellpakete dafür auf download.kde.org.
libx... kann man ruhig nach /usr installieren und dort alte Versionen überschreiben.
Obsolet ist genau das richtige Wort!
Aber es ist auch ungemein praktisch, da es die Pakete enthält die nicht Teil von KDE sind aber unbedingt benötigt werden, um es zu bauen. Da kann man sich sicher sein, dass die Versionsnummern passen.
Man sollte allerdings doppelte Libs vermeiden.
Bye
Thorsten
Ich wollte nicht von etwas schreiben, daß ich nicht kenne.
wenn du (mein Steckenpferd) KDE3 baust, wirst auch du bald feststellen, dass bei KDE die Pakete am einfachsten direkt aus dem CVS gesaugt werden ;-)
Du hast da den Vorteil, dass auch die Sourcen zur Verfügung stehen, die nicht öffentlich gepackt wurden, so gibt es seit heute
KDE-3rc3 ebenso seit gestern qt-3.0.3pre5(?).
Gerade wenn du deine Installation aus dem CVS machst (lässt sich ja auch wunderbar scripten!) lässt sich eine Installation simpelst einfach auf Stand bringen ohne jedes mal Megabyteweise gepackte Pakete runterladen zu müssen.
http://www.kde.org/anoncvs.html
Bye
Thorsten
QT aus dem CVS ist mir zu lästig ;-)
Wie man sicherlich schon an den vielen Verbesserungen gemerkt hat,
wollte ich die Anleitung auf das notwendigste beschränken.
Wenn jemand die Quellpakete erstmal kompiliert hat, kommt je nach Lust und Laune
der nächste Schritt namens Skripting, CVS, --enable-debug usw.
Erstaunlicherweise wird mit --enable-debug das System nicht linear mit den Dateigrößen langsamer, natürlich abhängig vom System.
Als newbie hätte ich keine Lust eine 1000zeilige Anleitung durchzugehen, die dafür komplett ist. Daher notwendigerweise die Unvollständigkeit.
KDE3 rulz !
Auch wenn es oft Ungereimtheiten gab, z.B. hatte ich trotz(?) schneller Verbindung die arts-Version 0.9.x und kdelibs wollte 0.9.x-1 ...
Da hört es für den newbie schon auf, Spaß zu machen.
--enable-debug=ARG enables debug symbols (yes|no|full) default=no
--disable-debug disables debug output and debug symbols default=no
Da disable-debug default-mäßig auf no steht, werden die Pakete _mit_ Debug-Symbolen bebaut, will man das nicht muss man ausdrücklich --disable-debug eingeben. Ein --enable-debug=no funktioniert AFAIK nicht!
Gruß
Thorsten
Das ist gar nicht möglich, da es das bis zur Sekunde nicht gibt.
-rw-r--r-- 1 jochen users 1147 Mär 15 14:40 kdelibs/kdecore/kdeversion.h
cat kdelibs/kdecore/kdeversion.h |grep rc3
#define KDE_VERSION_STRING "2.99 (3.0 rc3)"
> #define KDE_VERSION_STRING "2.99 (3.0 rc3)"
Und? Das wurde vor Tagen vorsorglich geändert damit es nicht wie bei rc2 vergessen wird (siehe dazugehörigen CVS Kommentar). Das Tag KDE_3_0_RELEASE steht noch immer auf Stand rc2. Es ist rc2 wenn es gepackt auf dem FTP-Server liegt _und_ (auch Erfahrung von rc2) als solches in der Mailing-Liste announct wurde.
kennt sich anscheinend gut aus.
Aber war es nicht so, dass Dirk HEAD in KDE_3_0_RELEASE "umkopiert" und dieses dann RC1..X nennt? Ich dachte, dass nur öffentliche Tarballs getaggt werden?
Von rc1/2 gibts ja auch kein Tag. Ich sehe ja auch keine Fixes im Release-Branch, die sind in HEAD!
Kann mich da aber auch irren?!
Bye
Thorsten
Da wird nichts umkopiert, es gibt derzeit genau einen KDE 3.x-Branch (HEAD) und ein Tag KDE_3_0_RELEASE was für die einzelnen Release Candidates verschoben wird.
> Ich dachte, dass nur öffentliche Tarballs getaggt werden?
Tarballs kann man gar nicht taggen. Die werden zu den einzelnen Zeitpunkten aus dem HEAD Branch mit dem TAG KDE_3_0_RELEASE, wo es dann gerade steht, erstellt.
> Von rc1/2 gibts ja auch kein Tag. Ich sehe ja auch keine Fixes im Release-Branch, die sind in HEAD!
Es gibt keine Release-Tags und auch derzeit keinen eigenen Release-Branch (erst für KDE 3.0.x dann wieder KDE_3_0_BRANCH).
Wesentlich würde ich sagen war dein Satz vorher:" RC3 ist raus, wenn es auf der ML verkündet wird"
Und, keine Lust dich zu outen?
Bye
Thorsten
Beziehen ist das ganze unter: http://asic-linux.com.mx/~izto/checkinstall
Einfach genial das Teil und optimal zum experimentieren !!
Auch wenn es jeder zweite kennt, eine Erwaehnung ist es allemal Wert ......
Gruesse
Johnny
entsprechender Passus rein, Dokumenten-GPL oder wie das hiess.
ich wollts mir mal reinziehen, unter debian woody. aber wenn ich es ./configure, dann bringt er mir nur:
checking for PLGetProplistWithPath in -lPropList... yes
checking for libcdaudio-config... no
checking for libcdaudio - version >= 0.99.0... no
*** The libcdaudio-config script installed by libcdaudio could not be found
*** If libcdaudio was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBCDAUDIO_CONFIG environment variable to the
*** full path to libcdaudio-config.
./configure: couldn't find libcdaudio: command not found
checking for cdda_find_a_cdrom in -lcdda_interface... no
checking for paranoia_init in -lcdda_paranoia... no
Error: could not find cdparanoia.
weiss jemand was man da machen kann...
libcdaudio0 und cdparanoia sind installiert...
mfg blueyellow
ich denke Du arbeitest?
Heiko
Bis Version 2.2.1 oder 2.2.0 hat auch alles wunderbar funktioniert.
Nur ab Version 2.2.2 und bei allen 3er Versionen komme ich bis zum 3. Element des Splashscreens. Dann kommt eine Meldung, dass Kicker abgestürzt ist (SIG 11). Im Output steht irgendwas von DCOP Communication Error und connection refused. Ich hab schon bei google gesucht, bin aber nicht richtig fündig geworden.
Vielleicht kann mir ja hier jemand helfen.