[gelöst] Apt verweigert Installation von kdeplasma-addons

[midrow]

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.

Code Select Expand

aptitude update  && aptitude -t experimental install ~S~i~Aexperimental-snapshots
Im übrigen ist mir aufgefallen, dass in der ursprünglichen siduction-preferences-Datei Null statt O steht (also 0=qt-kde):

Code Select Expand

Package: *
Pin: release 0=qt-kde,a=experimental-snapshots
Pin-Priority: 600 Das sollte doch nicht ganz ohne Auswirkungen sein/bleiben, oder?

[devil]

Da hast Du einen Bug gefunden. Ich hab das File vom Server genommen, da es zur Zeit eh nicht mehr gebraucht wird.

greetz
devil

[holgerw]

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

[holgerw]

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

[agaida]

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.

[ralul]

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!

[agaida]

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.

[ralul]

@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)

[devil]

ralul,
es ist automatisch auf 500 gepinnt, wenn man nix anderes möcbhte. Da muss man nyx für tun.

greetz
devil

[ralul]

Jo, stimmt, kapier aber jetzt überhaupt nix mehr.
Wie geht denn das, beide Versionen 4.7.4 sind doch Release experimental?
zB kdetoys:

Code Select Expand

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:

Code Select Expand

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

[ayla]

Man hat eine Unterscheidung, nähmlich die Quelle.

500 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?

[ralul]

@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?

[ayla]

Grad gesehen und auch ein edit gemacht

[ralul]

@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

[ayla]

Package: *
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.