[solved] python-sip will die aufgeführten Pakete killen.

[agaida]

Bei i686 wird, anders als bei amd64, python-sip nicht zurückgehalten und will die folgenden Pakete mit sich nehmen. Entweder manuell updaten oder Füsse stillhalten.

Frage: Abwarten oder reportbug bemühen?
 

Code: [Select]


root@kdebox:/home/agaida# apt-get install python-sip
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut      
Statusinformationen werden eingelesen... Fertig
Die folgenden Pakete werden ENTFERNT:
  gdebi-kde python-kde4 python-qt4
Die folgenden Pakete werden aktualisiert (Upgrade):
  python-sip
1 aktualisiert, 0 neu installiert, 3 zu entfernen und 0 nicht aktualisiert.
Es müssen 136 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 63,0 MB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]?
Abbruch.


Nachtrag: Im Endeffekt hängt das an Abhängigkeiten in der python-pt4. Dummerweise ist das Paket nicht so einfach neu zu bauen, es bricht an dieser Stelle ab:

Code: [Select]


In file included from /home/agaida/python-qt4/python-qt4-4.7.3/sip/QtXml/qxml.sip:212:
/usr/include/qt4/QtCore/qscopedpointer.h: In member function ‘QXmlParseException& QXmlParseException::operator=(const QXmlParseException&)’:
/usr/include/qt4/QtCore/qscopedpointer.h:170: error: ‘QScopedPointer<T>& QScopedPointer<T>::operator=(const QScopedPointer<T>&) [with T = QXmlParseExceptionPrivate, Cleanup = QScopedPointerDeleter<QXmlParseExceptionPrivate>]’ is private

An dieser Stelle kann ich nicht mal mehr einen sinnvollen Fehler formulieren oder auch einen Patch machen, da steig ich nicht mehr durch. QT ist Teufelswerk für mich.

[DonKult]

Einfache (temporäre) Uninstallierbarkeit ist keinen Bugreport wert - dafür ist unstable ja im Grunde da.

Das Pakete auf dem einen System entfernt werden und auf dem anderen nicht liegt nicht zwingend an der Architektur sondern kann auch am System liegen, da APT Entfernungsentscheidungen basierend auf dem aktuellen System trifft (grob gesagt: Was hängt davon im Vergleich zum anderen ab).

Eine Unbaubarkeit (FTBFS = Fail to build from source) hingegen ist ein Fehler, den man durchaus melden kann, da es sehr wichtig ist für Debian, dass alle Pakete baubar sind.

[agaida]

Ich hab mich da falsch ausgedrückt. Wird ein Paket zurückgehalten, weil Abhängigkeiten nicht erfüllt sind, sehe ich da kein Problem drin, da stimmen wir überein. Ein Paket, was nicht installiert, da geblockt, richtet erst mal keinen Schaden an. Find ich in Ordnung und richtig.

Im konkreten Fall ging es ja um i686 - Was mich irgendwie stört, ist grade das Verhalten von apt, das imho gleich sein sollte. Das ist jetzt nur so aus Interesse - kann man diese Entscheidungskriterien irgendwo einsehen oder auf "ein wenig konservativer" stellen?

Ich sehe da erst mal keinen Handlungsbedarf mehr, das Teil wurde schon mal als grave-bug gemeldet. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615163). Ich ergänze das nur noch darum, dass es nicht baubar ist.

[hschn]

Hallo agaida,
ich habe auch i686 installiert und bei mir wird python-sip schon seit (ich glaube 3 Tagen) anstandslos zurückgehalten. Ich schaue immer, wenn ich den PC einschalte, welche Pakete installiert werden und vor dem Ausschalten dann das dist-upgrade.
Also liegt es irgendwie auch an den installierten Paketen oder dem PC oder...

Viele Grüße
hschn

[agaida]

Im Endeffekt ist das alles sehr mysteriös. Das Ganze ging ja von bluelupo aus. Ich hab mich dann daran erinnert, dass ich noch ein paar VMs mit 32 bit hatte und konnte das Verhalten mühelos reproduzieren. Gegen ein sauberes Halten hätte ich nichts, wie bereits erwähnt.

[oduffo]

Auf meinem 32-bit-System wird python-sip nicht automatisch zurückgehalten.

Da ich einige Programme nutze, die python-qt4 benötigen, habe ich python-sip daher manuell auf hold gesetzt (python-sip-dev wird dann auch gehalten) und danach problemlos d-u gemacht.

Gruß
oduffo

[DonKult]

Im konkreten Fall ging es ja um i686 - Was mich irgendwie stört, ist grade das Verhalten von apt, das imho gleich sein sollte. Das ist jetzt nur so aus Interesse - kann man diese Entscheidungskriterien irgendwo einsehen oder auf "ein wenig konservativer" stellen?

Code: [Select]

$ apt-get dist-upgrade -o Debug::pkgProblemResolver=1 -s
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut      
Statusinformationen werden eingelesen... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Starting
Starting 2
Investigating (0) python-qt4 [ i386 ] < 4.7.3-1+b1 > ( python )
Broken python-qt4:i386 Hängt ab von on sip-api-7.1 [ i386 ] < none > ( none )
  Considering python-sip:i386 1 as a solution to python-qt4:i386 3
  Added python-sip:i386 to the remove list
  Fixing python-qt4:i386 via keep of python-sip:i386
 Try to Re-Instate (0) python-sip:i386
Done
…

Wie man sieht versucht APT Probleme zu lösen in dem es erstmal die Wichtigkeit von Paketen berechnet (Debug::pkgProblemResolver::ShowScores) und dann mit dem wichtigsten beginnend nachsieht welches Probleme hat. In dem Falle hat python-qt4 (3 Punkte) ein Problem mit python-sip (1 Punkt) -- also muss sich python-sip unterordnen, was in diesem Falle bedeutet es wird zurückgehalten um das Problem aufzulösen.

Würden jetzt mehr Pakete von python-sip abhängen (was offensichtlich davon abhängt was man so installiert hat, also vom System), dann kommt es vielleicht irgendwann zur Situation das python-sip wichtiger wird als python-qt4, womit dann die Entscheidung anders ausfallen wird (vermutlich Entfernung von python-qt4).

Rumspielen kann man sehr begrenzt damit, aber wirklich empfehlen würde ich das eh nicht den die Einstellungen sind über Jahre gereift, das wird man kaum auf die schnelle besser machen können.

Man muss bedenken, das dist-upgrade eben nicht für die Zartbeseiteten gedacht ist: Upgrade alles was irgendmöglich ist und versuch hinterher zu retten was zu retten ist. Die Strategie hört sich richtig doof an - ist sie auch - funktioniert aber ausgesprochen gut. Intelligentere Strategien haben die Angewohnheit mehr Probleme zu bereiten, da die Gegebenheiten in unstable eben ziemlich rau sind. Da ist doof sehr praktisch weil in den wenigen Momenten wo es zu doof ist weiß man wenigstens sicher warum.

Immer getreu dem Motto: Wenn ein Programmierer ein Programm schreibt, was so intelligent ist wie er selbst, dann ist es ihm unmöglich dieses Programm jemals zu warten - den um Fehler darin zu entdecken, müsste er schlauer sein…

[bluelupo]

also bei meinen 64Bit System wird das python-sip definitiv nicht automatisch zurückgehalten und das bewerte ich persönlich als Bug des Debian Paketbauers, zumal es bei 32Bit Systemen anstandlos funktioniert.

[towo]

Also nachdem es hier (64bit) das erste mal automatisch aktualisiert wurde, hab ich es aus Testing wieder installiert, da ich reportbug-ng brauche. Seit dem wird es hier auch automatisch zurückgehalten.

[mylo]

also bei meinen 64Bit System wird das python-sip definitiv nicht automatisch zurückgehalten u....

bei mir schon (64 bit).

[agaida]

@DonKult: Danke für die Erklärung, habs begriffen. Find ich irgendwie gut. Draufhauen und danach die Toten zählen entspricht auch so ziemlich meiner Mentalität bei updates. Damit kann ich gut leben.

[devil]

wie Donkult schon sagte, kann es je nach paketbestand ganz anders aussehen: trotz installiertem python-sip wird es nicht gehalten sondern python-qt entfernt:

Code: [Select]

root@devbox:/home/devil# apt-get dist-upgrade -o Debug::pkgProblemResolver=1 -s
Paketaktualisierung (Upgrade) wird berechnet... Starting
Starting 2
Investigating (0) python-qt4 [ i386 ] <4> ( python )
Broken python-qt4:i386 Hängt ab von on sip-api-7.1 [ i386 ] <none> ( none )
  Considering python-sip:i386 4 as a solution to python-qt4:i386 4
  Removing python-qt4:i386 rather than change sip-api-7.1:i386
Investigating (0) python-kde4 [ i386 ] <4> ( python )
Broken python-kde4:i386 Hängt ab von on python-qt4 [ i386 ] <4> ( python )
  Considering python-qt4:i386 4 as a solution to python-kde4:i386 3
  Removing python-kde4:i386 rather than change python-qt4:i386
Investigating (0) reportbug-ng [ i386 ] <1> ( utils )
Broken reportbug-ng:i386 Hängt ab von on python-qt4 [ i386 ] <4> ( python )
  Considering python-qt4:i386 4 as a solution to reportbug-ng:i386 0
  Removing reportbug-ng:i386 rather than change python-qt4:i386
Investigating (0) krusader [ i386 ] <1> 1:2.3.0~beta1-1 > ( utils )
Broken krusader:i386 Hängt ab von on libkonq5 [ i386 ] <none> 4:4.4.5-2 > ( libs ) (>= 4:4.3.4)
  Considering libkonq5:i386 1 as a solution to krusader:i386 0
  Holding Back krusader:i386 rather than change libkonq5:i386
Investigating (0) plasma-scriptengine-python [ i386 ] <4> ( kde )
Broken plasma-scriptengine-python:i386 Hängt ab von on python-kde4 [ i386 ] <4> ( python ) (>= 4:4.2.0)
  Considering python-kde4:i386 3 as a solution to plasma-scriptengine-python:i386 0
  Removing plasma-scriptengine-python:i386 rather than change python-kde4:i386
Investigating (0) backintime-kde [ i386 ] <1> ( utils )
Broken backintime-kde:i386 Hängt ab von on python-kde4 [ i386 ] <4> ( python )
  Considering python-kde4:i386 3 as a solution to backintime-kde:i386 -1
  Removing backintime-kde:i386 rather than change python-kde4:i386
...
Die folgenden Pakete werden ENTFERNT:
  backintime-kde plasma-scriptengine-python python-kde4 python-qt4 reportbug-ng

greetz
devil

[agaida]

Code: [Select]


#616139: python-kde4: kdebindings do not build
...
  Bug#616139: fixed in kdebindings 4:4.4.5-4
From:
"Debian Qt/KDE Maintainers" <debian>
  To:
616139-close@bugs.debian.org
Source: kdebindings
Source-Version: 4:4.4.5-4

We believe that the bug you reported is fixed in the latest version of
kdebindings, which is due to be installed in the Debian FTP archive:


Es besteht also berechtigter Grund zur Hoffnung

[agaida]

Und erledigt, sollte in den Spiegeln eintrudeln. auf ftp.de.debian.org ist amd64 und i686 verfügbar, auf beiden Plattformen hats problemlos installiert.

[devil]

kann ich genauso bestätigen

greetz
devil