[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing



Merci Étienne, 
Actuellement j'ai du arrêter mon travail de la migration 32 bits--64 bits car 
je suis en dehors de chez moi.
Je n'ai pas tenu au courant la liste des progrès dans cette migration .
J'avais réussi à passer ce problème en modifiant comme l'indique  Étienne le 
script /var/lib/dpkg/info/python3-pil:i386.prerm et tout alors à fonctionner à 
merveille, sauf .... et c'est là que je me suis arrêter.
Quand j'ouvre une session avec Kdm j'obtiens un écran gris et le plus étrange 
c'est que la souris fonctionne, en examinant  attentivement on voit que le 
serveur X marche également
En regardant .Xsession-errors on voit une erreur que je retranscris de mémoire 
Kdm[1401] pam_ck_connector (kde:session) : noX11 mode ....
Je me suis dit puisque Kdm me joue un tour essayons Sddm et là un autre 
problème impossible d'ouvrir une session car impossible de passer la phase 
authentification tous mes comptes sont refusés.
Remarque : J'avais déjà ce problème en 32 bits mais comme Kdm fonctionnait je 
me disais que je regarderais ce problème plus tard.
Voilà ou j'en suis de ma migration et étant actuellement  loin du poste 
incriminé, je ne peux continuer mes recherches.
Encore merci.
Philippe Merlin


Le vendredi 12 mai 2017, 23:07:25 CEST Étienne Mollier a écrit :
> On 05/06/2017 06:50 PM, MERLIN Philippe wrote:
> > Bonsoir,
> > J'avance péniblement dans cette migration et j'espérais arriver
> > à la fin
> > Las !!!
> > J'arrive à obtenir un apt-get -f install qui semble cohérent
> > sauf  que python3 a frappé et me bloque, je ne sais pas comment
> > m'en sortir.
> 
> Bonsoir Philippe,
> 
> J'ai pris un peu de temps pour sauvagement torturer une VM Debian
> afin de voir si j'arrivais à me retrouver dans la même situation.
> Plein de problèmes se sont produits, mais celui-ci je n'ai pas
> réussi à le voir passer, faute d'avoir pu réussir à atteindre la
> fin de mon second crossgrade sans tout casser.  Ceci dit, ça m'a
> permis d'avoir peut-être une idée pour décoincer la situation...
> 
> > Les scripts de python3 semblent ne pas avoir envisager la
> > possibilité d'avoir un instant donné deux versions d'un paquet
> > i386 et amd64 si bien que dpkg -L paquet sort en erreur, à la
> > main un dpkg -l paquet:i386 marche très bien.
> > 
>
>         #!/bin/sh
>         set -e
> 
>         # Automatically added by dh_python3:
>         if which py3clean >/dev/null 2>&1; then
>                 py3clean -p python3-pil
>         else
>                 dpkg -L python3-pil | perl -ne
> 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $!
> foreach glob($_)'
>                 find /usr/lib/python3/dist-packages/ -type d -name
> __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir
>         fi
> 
>         # End automatically added section
> 
> La ligne qui produit l'erreur est très probablement celle en
> `dpkg -L python3-pil | ...' qui gagnerait à être rédigée sous la
> forme `dpkg -L python3-pil:i386 | ...'.  La correction peut être
> effectuée dans le script enregistré par `dpkg' à l'installation
> de python3-pil, et qui devrait se nommer
> 
>         /var/lib/dpkg/info/python3-pil:i386.prerm
> 
> ou si l'architecture n'est pas présente (mais je crains une
> confusion avec le paquet 64bits dans ce cas) :
> 
>         /var/lib/dpkg/info/python3-pil.prerm
> 

> À plus,



Reply to: