Hallo zusammen,
bin endlich auch auf siduction umgestiegen :D (parallel läuft noch ein aptosid).
Zum Thema:
Beim Versuch, kdeplasma-addons zu installieren, gibt Apt seit mehreren Tagen Folgendes aus:
# apt-get install kdeplasma-addons
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
kdeplasma-addons : Hängt ab von: plasma-widgets-addons (>= 4:4.6.5-1) soll aber nicht installiert werden
Hängt ab von: plasma-widget-lancelot (>= 4:4.6.5-1) soll aber nicht installiert werden
E: Beschädigte Pakete
Kann es wirklich sein, dass einige Pakete immer "noch nicht erstellt wurden"?
Was kann man da tun? Ein "force" will ich vermeiden ...
Bis bald
midrow
Das Problem ist, dass KDE 4.7.2 im qt-kde.debian.net Repository nicht mehr existiert. Es gibt derzeit nur 4.6.5 in sid (zu alt für deine Install) und 4.7.4 in experimental. das hab ich seit 6 wochen im täglichen Einsatz ohne Probleme.
Du kannst mal versuchen, ob:aptitude update && aptitude -t experimental install ~S~i~Aexperimental-snapshots funktioniert. Sollte es eigentlich, nachdem Du aptitude installiert und deb http://ftp.de.debian.org/debian/ experimental mainin Deine debian.list eingetragen hast. Danach kannst Du auch kdeplasma-addons installieren.
Rückmeldung, ob das so noch funktioniert, wäre nett.
greetz
devil
Hallo devil,
danke für die schnelle Antwort! :D
Quote from: "devil"Das Problem ist, dass KDE 4.7.2 im qt-kde.debian.net Repository nicht mehr existiert. Es gibt derzeit nur 4.6.5 in sid (zu alt für deine Install) und 4.7.4 in experimental. das hab ich seit 6 wochen im täglichen Einsatz ohne Probleme.
Hatte etwas in dieser Richtung vermutet ...
QuoteDu kannst mal versuchen, ob:aptitude update && aptitude -t experimental install ~S~i~Aexperimental-snapshots funktioniert.
Während der ganzen sidux/aptosid-Zeit ist mir eingeimpft worden, aptitude nicht zu verwenden! Hab das auch noch nie benutzt! Weiß nur, dass ralul ein emsiger Verfechter dieser Software ist.
Nach Einbinden von
experimental müsste das doch auch mit apt-get gehen, ich wüsste dann nur gerne die Äquivalente von
~S~i~A ...
midrow
Nein, apt-get kann das nicht. Das Problem mit aptitude, bzw. dessen Geisselung bei sidux/aptosid ist mehr oder weniger rein psychologischer Natur. aptitude hat generell einen besseren solver als apt, ist dadurch aber auch komplizierter, was bei sid besonders zum tragen kommt. Hinzu kam bis vor einiger Zeit die tatsache, dass man beide nicht nebeneiander verwenden sollte. Das gilt nicht mehr. Du kannst obigen Befehl ohne weiteres ausführen.
greetz
devil
Entschuldigt, wenn ich mich kurz reinhänge:
Mit welchem Befehl installiere ich KDE komplett aus experimental?
mit apt-get install -t experimental kde-window-manager gabs wohl nur nen Teil...
Denn ein "apt-show-versions --upgradeable" zeigt mir noch recht vieles, was ich noch "manually" upgraden kann...
Lanzi,
obiger Befehl installiert das aus experimental, was als -aus experimental-snapshots installiert- markiert ist. Das gilt halt nur für frische siduction Installs oder für Installs, die per Hand aus dem qt-kde Repo auf 4.7.2 hochgezogen wurden.
greetz
devil
kann man denn nicht kde komplett aus experimental ziehen?
ich probiere oberen Befehl mal aus. hatte ja alles aus experimental-snapshots.
Ich hätte gerne kde ganz auf 4.7.4. Ich meine, spätestens, wenn mal alles nach SID kommt, wärs ja auch erledigt, aber das dauert ja schon wieder recht lang mit 4.7...
Damit bekommst Du es doch komplett, alles,was du an KDE installiert hast. Was 4.7.4 in sid angeht: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653919
Interessant (und traurig) ist vor allem der letzte Post.
greetz
devil
In der Tat. Schon sehr nerdig...
Es scheint, als ob die zunehmende Komplexität kaum noch zu bewältigen ist... Allerdings erinnere ich mich, dass Du mal sagtest, dass es wohl auch an mangelnder Manpower liegt...
Die mangelnde Manpower besteht durchaus, sowohl bei qt-kde-debian als auch im Release-Team. Letztere kann als einzige diese irrwitzige Situation auflösen, was einer Entscheidung, ein paar Mails an die Maintainer und 10 Minuten Arbeit bedarf. Ich denke das Ganze zeigt exemplarisch, was KDE in Debian wert ist.
greetz
devil
Dein letzter Satz ist vermutlich die Qunintessenz aus alldem...
Umso bedauerlicher, wen man bedenkt, wie einseitig Linux werden würde, wenn es nur Gnome und unity gäbe... (lxde und xfce mal außen vor)
Quote from: "devil"Nein, apt-get kann das nicht. Das Problem mit aptitude, bzw. dessen Geisselung bei sidux/aptosid ist mehr oder weniger rein psychologischer Natur. aptitude hat generell einen besseren solver als apt, ist dadurch aber auch komplizierter, was bei sid besonders zum tragen kommt. Hinzu kam bis vor einiger Zeit die tatsache, dass man beide nicht nebeneiander verwenden sollte. Das gilt nicht mehr. Du kannst obigen Befehl ohne weiteres ausführen.
Das Ergebnis nach "aptitude update":
# aptitude -t experimental install ~S~i~Aexperimental-snapshots
Es werden keine Pakete installiert, aktualisiert oder entfernt.
0 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 316 nicht aktualisiert.
Muss 0 B an Archiven herunterladen. Nach dem Entpacken werden 0 B zusätzlich belegt sein.
Dann hast Du siduction wahrscheinlich nicht frisch installiert. Auch hier kann geholfen werden. Downloade http://pkg-kde.alioth.debian.org/files/kde-experimentalund speichere es als /etc/apt/preferences.d/kde-experimental
Danach ein apt-get update && apt-get dist-upgrade.
Solltest Du bereits ein preferences-file in /etc/apt/ oder unter /etc/apt/preferences.d haben, solltest Du sehr genau wissen, was Du tust.
greetz
devil
Quote from: "devil"Dann hast Du siduction wahrscheinlich nicht frisch installiert.
Doch, habe ich! :!:
In /etc/apt/preferences steht:
Package: *
Pin: release 0=qt-kde,a=experimental-snapshots
Pin-Priority: 600
/etc/apt/preferences.d/ ist (noch) leer.
QuoteSolltest Du bereits ein preferences-file in /etc/apt/ oder unter /etc/apt/preferences.d haben, solltest Du sehr genau wissen, was Du tust.
Sehr genau weiß ich das nicht, allenfalls grob. Hab mich mit den preferences bisher nur wenig beschäftigt.
Werde mir das Ganze später am Sonntag mal näher anschauen ...
Bis bald
midrow
Ersetze das vorhandene File mit dem von mir verlinkten.
greetz
devil
Quote from: "devil"Ersetze das vorhandene File mit dem von mir verlinkten.
Das habe ich inzwischen gemacht, ein D-U funktionierte reibungslos und nun ließ sich auch kdeplasma-addons installieren.
Da ich Dingen aber gerne auf den Grund gehe, würde mich trotzdem interessieren, warum devils erster Tipp mit aptitude nicht funktioniert hat, denn ich hatte ja – wie gesagt – eine frische siduction-Neuinstallation vorliegen.
aptitude update && aptitude -t experimental install ~S~i~Aexperimental-snapshotsIm übrigen ist mir aufgefallen, dass in der ursprünglichen siduction-preferences-Datei Null statt O steht (also 0=qt-kde):
Package: *
Pin: release 0=qt-kde,a=experimental-snapshots
Pin-Priority: 600 Das sollte doch nicht ganz ohne Auswirkungen sein/bleiben, oder?
Da hast Du einen Bug gefunden. Ich hab das File vom Server genommen, da es zur Zeit eh nicht mehr gebraucht wird.
greetz
devil
Hallo,
wer mutig ist, kann die kde-experimental noch um digikam, digikam-data, digikam-dbg, kipi-plugins und kipi-plugins-common erweitern. Dann bekommt Ihr das taufrische digikam 2.6.0 Beta1.
Viele Grüße,
Holger
Quote from: "devil"Die mangelnde Manpower besteht durchaus, sowohl bei qt-kde-debian als auch im Release-Team. Letztere kann als einzige diese irrwitzige Situation auflösen, was einer Entscheidung, ein paar Mails an die Maintainer und 10 Minuten Arbeit bedarf. Ich denke das Ganze zeigt exemplarisch, was KDE in Debian wert ist.
greetz
devil
Hallo Ferdinand,
schade ist meines Erachtens hier auch, dass darunter die zügige Integration von KDE4.8 mit dem neuen kdepim leidet. Denn dort sind die Schwierigkeiten mit kmail2 und imap wohl mittlerweile behoben. Ich habe es in OpenSUSE mal kurz getestet, ich muss nicht mehr lange warten beim Klick auf einzelne Nachrichten und auch nach der kmail2 Benutzung ist die Mailordnerstruktur weiterhin in Ordnung.
Viele Grüße,
Holger
The Times are changing.
KDE 4.7.4 kann man ab gestern aus unserem eigenen kde-next repo beziehen. Devil war so nett, da was im Blog zu zu schreiben:
http://news.siduction.org/2012/02/kde-next-repository/
@holgerw
irrwitzig oder aberwitzig bescheibt das Ganze recht gut. Wäre ich nicht Novell-Geschädigter, wäre Suse eine Alternative. So ist es das aber nicht.
Es ist schon interessant, wie grandios Dinge schieflaufen können. Zum Glück kann man ja im kleinen Rahmen einige Entscheidungen ein wenig entschärfen. Eine andere Variante wäre es, bei debian für mehr Man-Power zu sorgen.
Nicht in den falschen Hals bekommen: Ich stehe für so was auf keinen Fall zu Verfügung. Dazu müsste sich das Klima und die Arbeitsweise bei debian drastisch ändern. Oder die Hölle zufrieren. Ich revidiere meine Einschätzung der Lage gerne, wenn eines der genannten Ereignisse eintritt. Das Zufrieren der Hölle ist leider die Option, die wahrscheinlicher ist.
Ist es schlau dieses neue Repo auch mit dem Release "experimental" zu taggen?
Meiner Ansicht nach ist Kde-4.7.4 von der Stabilität her schon als unstable gedacht. Der Nachteil ist nämlich, man hat keine Unterscheidung, wenn man auch Debian experimental braucht - dann verbessert sich nix!
ralul - Du schreibst wirr. ;)
Man hat eine Unterscheidung, nähmlich die Quelle. Und da das Pinning von next auf 500 liegt, wird nichts passieren. Wer natürlich die Priorität von experimental so weit hochsetzt, dass exp als normales Repository angezogen wird, der hat andere Probleme. Aber nicht lange.
Das umlablen der Pakete überlass ich gerne dem Upstream, Namen sind in diesem Fall Schall und Rauch.
@agaida, stimmt, das Release einer Paketes ist im Paket selbst definiert! Tschuldigung, ich dachte man könnte einfach nur unser kdenext Repository zu unstable erheben.
Wie mach ich das Pinning der Quelle next? Habt ihr das in einem MetaPaket configuriert? (Ich habe wohl nicht alle siduction Pakete)
ralul,
es ist automatisch auf 500 gepinnt, wenn man nix anderes möcbhte. Da muss man nyx für tun.
greetz
devil
Jo, stimmt, kapier aber jetzt überhaupt nix mehr.
Wie geht denn das, beide Versionen 4.7.4 sind doch Release experimental?
zB kdetoys:
root@maci:/etc/apt# apt-cache policy kdetoys
kdetoys:
Installiert: (keine)
Kandidat: 4:4.7.4-1
Versionstabelle:
4:4.7.4-1 0
1 http://ftp.de.debian.org/debian/ experimental/main amd64 Packages
500 http://packages.siduction.org/kdenext/ experimental/main amd64 Packages
4:4.6.5-1 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
Da ich aber ein experimental enabled brauche, muss ich priorities setzen und bin gebissen:
root@maci:/etc/apt# apt-cache policy kdetoys
kdetoys:
Installiert: (keine)
Kandidat: 4:4.6.5-1
Versionstabelle:
4:4.7.4-1 0
103 http://ftp.de.debian.org/debian/ experimental/main amd64 Packages
103 http://packages.siduction.org/kdenext/ experimental/main amd64 Packages
4:4.6.5-1 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
Quote from: "agaida"
Man hat eine Unterscheidung, nähmlich die Quelle.
Quote500 http://packages.siduction.org/kdenext/ experimental/main amd64 Packages
Ich denke das ist die Antwort?
Edit: Wieso, wenn du dem kdenext die höhere Priorität gibst müsste das doch klappen?
@ayla ich hab noch was zugesetzt, warum ich gebissen bin - oben.
Wie ich es verstehe, ist nur Debian-experimental automatisch auf 1 runtergesetzt, ich meine ohne preferences-Priorities?
Grad gesehen und auch ein edit gemacht :)
@ayla, das war ja gerade meine Frage, wie gebe ich dem kdenext eine erhöhte Priorität ?
geht alles nicht:
Package: *
Pin: release o=siduction.org
Pin-Priority: 505
Package: *
Pin: release o=siduction
Pin-Priority: 505
Package: *
Pin: release o=kdenext
Pin-Priority: 505
QuotePackage: *
Pin: origin packages.siduction.org
Pin-Priority: 600
funktioniert dies?
EDIT:
ok ich glaube ich hab erst jetzt kapiert wo dein Problem liegt.
Sobald du debian "experimental" pinnst geht das kdenext, da auch "experimental" mit?
Wäre es denn eine Lösung wenn du die normalen debian repos über einen anderen Server beziehst als das experimental und dann diesen Server per "origin" pinnst?
Nur so einen Idee, kanns im Moment nicht selbst ausprobieren.
@ayla, schöne idee, wenn es ginge
Aber ich habe die syntax nicht raus :(
Pin: origin packages.siduction.org
geht auch nicht.
hmm, bei mir hatte das wie im Zitat des letzten Posts funktioniert.
musst Du möglicherweise das pinnen des "experimental" erst rausnehmen bevor das andere wirksam werden kann?
Sorry, wie schon gesagt, kann erst heut abend wieder ausprobieren.
Das ganze ist wahrscheinlich auch noch undefiniert und funktioniert vielleicht sogar verschieden bei apt oder aptitude. Jedenfalls bei Änderung der Reinenfolge:
root@maci:/etc/apt# apt-cache policy kdetoys
kdetoys:
Installiert: (keine)
Kandidat: 4:4.7.4-1
Versionstabelle:
4:4.7.4-1 0
905 http://ftp.de.debian.org/debian/ experimental/main amd64 P....
905 http://packages.siduction.org/kdenext/ experimental/main amd64 P...
4:4.6.5-1 0
705 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
---
Reihenfolge in /etc/apt/preferences ändern
---
root@maci:/etc/apt# apt-cache policy kdetoys
kdetoys:
Installiert: (keine)
Kandidat: 4:4.7.4-1
Versionstabelle:
4:4.7.4-1 0
905 http://ftp.de.debian.org/debian/ experimental/main amd64 P...
990 http://packages.siduction.org/kdenext/ experimental/main amd64 P...
4:4.6.5-1 0
705 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
Die /etc/apt/prefecences war dabei
Package: *
Pin: origin packages.siduction.org
Pin-Priority: 990
Package: *
Pin: release a=experimental
Pin-Priority: 905
Package: *
Pin: origin ftp.de.debian.org
Pin-Priority: 705
Package: *
Pin: release a=unstable
Pin-Priority: 500
Wobei ich 990 packages.siduction.org beim ersten Mal unten hatte. Also funktionierte vorhin origin deswegen nicht.
ja, es ist auch die Reihenfolge, wer zuerst kommt malt zuerst. Ich glaube mit folgender Datei bin ich wieder zufrieden, denn durch editieren der Datei geht alles und ich bin flexibel.
/etc/apt/preferences:Package: *
Pin: origin packages.siduction.org
Pin-Priority: 501
Package: *
Pin: release a=experimental
Pin-Priority: 105
Package: *
Pin: release a=unstable
Pin-Priority: 501
ralul, ich verstehe wirklich nicht, wo Dein Problem lag/liegt, vielleich hab ich ja was verpasst. ;) Long story short: Es ist für die KDE-Pakete, die wir in KDE-Next extrahiert haben, vollkommen wurst, wo die hergezogen werden. Die sind in experimental und in unserem Repo vollkommen identisch. Die Idee, das eine Repo auf origin und das andere auf Distribution zu pinnen erschließt sich mir nicht wirklich.
Vielleich werden im Folgenden die Intentionen klarer: Wenn ich mit apt-get installiere, dann sollte bei nicht grob erhöhter Prio immer das kdenext gezogen werden. Und zwar ohne -t exp... Woher der dann Abhängigkeiten nachzieht, ist Wurst. Der einzige Zustand, der durch die Vorfilterung verhindert wird, ist das clientseitige Pinnig auf Einzelpakete aus experimental. Diese Arbeit haben wir $user abgenommen durch das partial mirroring, das einem Pinning entspricht. Sollte eigentlich recht trivial sein, aber ich kam mir auch leicht bescheuert vor, als ich das für mich ausgeknobelt habe und auf einmal gemerkt habe, dass es wirklich so einfach ist.
Es ist nicht immer so simpel. Pinning ist, je nach Szenario, alles andere als trivial. Einen kleinen einblick gibt Punkt 3.10 im apt-howto (http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html). Weiterführend die sehr gute Manpage zu apt_preferences.
greetz
devil
Nachtrag: Kritisch kann es nur werden, wenn updates gegen experimental gezogen werden. Sollte aber eigentlich auch nichts tun, weil die normalen Sidpakete sich nur in gewollten Ausnahem direkt im experimental bedienen. Für kdenext bedeutet das: Ziehe die aktuelle Version deiner Abhängigkeit daher, wo sie neuer ist, wenn im eigenen Teich was veraltetes drin ist. Macht in so fern nichts, da zeitnah eine neue Version in experimental durch den stündlichen Abgleich in Next landet.
(So - ich hoffe nur, dass ich mich halbwegs verständlich ausgedrückt habe und das auch fachlich in Ordnung ist. Wenn nicht, in beiden Fällen: Sorry - ich kanns halt nicht wirklich besser, aber ich arbeite dran)
@Agaida, ich wollte für mich nur schauen, wie ich eine Flexibilität künftig erreichen kann: Ich probier ja oft was aus dem Debian experimental aus.
@devil, ich hatte ja schon of in Bugs gelesen - besonders viel lese ich aptitude Bugs, dass da dann da mal was nicht stimmt, wenn man die Prioritäten explizit nutzt. Ist jetzt auch kein Wunder mehr für mich, denn da kann man einige sich widersprechende Angaben machen. Allein schon meine kleine Einstellung oben ist ja überschneidend, quer als Kreuz ist verschieden gesetzt: Herkunft versus Release.
Aber so isses wohl, wie ich es will :)
@Ayla, danke auch für Deinen Hinweis per PM. Hatte ich heute Nachmittag nicht so schnell gesehen. Das Forum macht leider keine augenfällige Unterscheidung zwischen:
Du hat keine neuen Nachricht
Du hast eine neue Nachricht
Quote from: "ralul"Ist jetzt auch kein Wunder mehr für mich, denn da kann man einige sich widersprechende Angaben machen. Allein schon meine kleine Einstellung oben ist ja überschneidend, quer als Kreuz ist verschieden gesetzt: Herkunft versus Release.
Aber so isses wohl, wie ich es will :)
@Ayla, danke auch für Deinen Hinweis per PM. Hatte ich heute Nachmittag nicht so schnell gesehen. Das Forum macht leider keine augenfällige Unterscheidung zwischen:
Du hat keine neuen Nachricht
Du hast eine neue Nachricht
Würde es nicht so:
Quote#siduction
Package: *
Pin: origin packages.siduction.org
Pin-Priority: 501
#debian main contrib...
Package: *
Pin: origin de.debian.org
Pin-Priority: 500
#debian experimental
Package: *
Pin: origin cz.debian.org
Pin-Priority: 103
bei entsprechend aufgebauter sources.list auch ohne Überschneidungen funktionieren? Wenn man wollte könnte man siduction ja auch noch über den amerikanischen server splitten.
Und was die Benachrichtigung betrifft: Jow, könnte man, wenn möglich, im neuen Forum etwas auffälliger machen.
@ayla, sehr schön. Zum Beispiel wenn ich dann auf Debian experimental ändern will mit dieser /etc/apt/preferences
Package: *
Pin: origin packages.siduction.org
Pin-Priority: 501
#experimental
Package: *
Pin: origin ftp.cz.debian.org
Pin-Priority: 503
Package: *
Pin: origin ftp.de.debian.org
Pin-Priority: 501
dann kommt:
root@maci:/etc/apt# apt-cache policy kdetoys
kdetoys:
Installiert: (keine)
Kandidat: 4:4.7.4-1
Versionstabelle:
4:4.7.4-1 0
503 http://ftp.cz.debian.org/debian/ experimental/main amd64 Packages
501 http://packages.siduction.org/kdenext/ experimental/main amd64 Packages
4:4.6.5-1 0
501 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
Um es mal ganz deutlich zu sagen:
Wer das kdenext repo benutzt und ebenso debian experimental, braucht kein pinning irgendeiner Art.
Wenn ihr weiter über pinning in diesem Zusammenhang diskutieren wollt, wäre 'Experimental' wahrscheinlich das richtige Forum. Hier, bei 'Installation' verwirrt es eher.
greetz
devil
Das heutige DU geht gut durch mit dieser /etc/apt/preferences
#
#experimental
Package: *
Pin: origin ftp.cz.debian.org
Pin-Priority: 103
Package: *
Pin: origin ftp.de.debian.org
Pin-Priority: 501
Package: *
Pin: origin packages.siduction.org
Pin-Priority: 501mit dieser /etc/apt/sources.list
# experimental
deb http://ftp.cz.debian.org/debian experimental main contrib non-free
#
# unstable sid
deb http://ftp.de.debian.org/debian unstable main contrib non-free
# deb-src http://ftp.de.debian.org/debian/ unstable main contrib non-free
#
# siduction
deb http://packages.siduction.org/kdenext experimental main
deb http://packages.siduction.org/siduction unstable main contrib non-free
deb http://packages.siduction.org/fixes unstable main contrib non-free
# deb http://packages.siduction.org/community unstable main contrib non-free
# deb http://packages.siduction.org/user unstable main contrib non-free
# deb http://packages.siduction.org/experimental unstable main contrib non-freeergibt:
root@maci:/etc/apt# apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete werden ENTFERNT:
libvlccore4
Die folgenden NEUEN Pakete werden installiert:
libresid-builder0c2a libsidplay2 libvlccore5 libxcb-composite0 libxcb-xfixes0
Die folgenden Pakete werden aktualisiert (Upgrade):
bind9-host iceweasel libbind9-80 libdns81 libisc83 libisccc80 libisccfg82 liblwres80 libmozjs10d
libvlc5 vlc vlc-data vlc-nox vlc-plugin-notify xulrunner-10.0
15 aktualisiert, 5 neu installiert, 1 zu entfernen und 0 nicht aktualisiert.
Es müssen 30,6 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 718 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?
[edit - sehe gerade devil]
@devil,
Aber falsch ist obiges auch nicht - ok, man braucht es nicht, wenn man nichts aus Debian experimental will. Aber zB Holgerw im anderen Thread will digikam. Braucht man dann nicht das Debian experimental mit Priorität 101 ?
@devil, und der ganze Thread, den ich am Ende hier gekapert habe, würde besser unter einem fortgeschrittenen Forum gehören, Tschuldigung.
ralul,
da nimmt man einfach -t experimental
greetz
devil
@Devil:
Durch lesen in diesem Thread bekomme ich nun mit, dass es die new.siduction.org Seite gibt.
Keine Kritik, aber warum haben wir unter Siduction.org zwei news Sektionen (die zweite unter siduction.org)?
Wird das beim relaunch der Seite zusammengefasst?
VG
Ich versteh zwar nicht, was Du meinst, aber unter news.siduction.org befindet sich ein 2-sprachiges Blog.
greetz
devil
und hier sind auch News
http://siduction.org/index.php?module=news
macht zusammen zweimal deutschsprachige News...
Nicht wirklich. Die News hier auf der Plattform sind direkt siduction-related. Das Blog ist eher thematisch weitläufig.
greetz
devil
Naja, ich fand den Blog jetzt genau richtig und lesenswert, weil er die News zur kommenden Siduction und KDE-Next enthielt. Wohingegen der andere newsbereich fast nie Neuigkeiten liefert - aber derjenige ist, der auf der Hauptseite verlinkt ist.
Denkt mal über eine Zusammenlegung nach ;-)
So und nun backt to topic ;-)