Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing
2 réponses
MERLIN Philippe
Bonsoir,
J'avance p=E9niblement dans cette migration et j'esp=E9rais arriver =E0 la =
fin=20
Las !!!
J'arrive =E0 obtenir un apt-get -f install qui semble coh=E9rent sauf que =
python3=20
a frapp=E9 et me bloque, je ne sais pas comment m'en sortir.
Les scripts de python3 semblent ne pas avoir envisager la possibilit=E9 d'a=
voir=20
un instant donn=E9 deux versions d'un paquet i386 et amd64 si bien que=20
dpkg -L paquet sort en erreur, =E0 la main un dpkg -l paquet:i386 marche tr=
=E8s=20
bien.
Voici la sortie d'erreur :
Suppression de python3-pil:i386 (4.0.0-4) ...
dpkg-query: erreur: --listfiles requiert un nom de paquet l=E9gal. =AB pyth=
on3-p
il =BB ne l'est pas ; nom de paquet =AB python3-pil =BB ambigu avec plus d'=
une=20
instance install=E9e
Utiliser --help pour de l'aide sur la recherche de paquets.
Traceback (most recent call last):
File "/usr/bin/py3clean", line 210, in <module>
main()
File "/usr/bin/py3clean", line 196, in main
pfiles =3D set(dpf.from_package(options.package))
File "/usr/share/python3/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-pil
dpkg: erreur de traitement du paquet python3-pil:i386 (--remove) :
le sous-processus script pre-removal install=E9 a retourn=E9 une erreur de=
sortie=20
d'=E9tat 1
dpkg-query: erreur: --listfiles requiert un nom de paquet l=E9gal. =AB pyth=
on3-p
il =BB ne l'est pas ; nom de paquet =AB python3-pil =BB ambigu avec plus d'=
une=20
instance install=E9e
Utiliser --help pour de l'aide sur la recherche de paquets.
Traceback (most recent call last):
File "/usr/bin/py3compile", line 290, in <module>
main()
File "/usr/bin/py3compile", line 270, in main
options.force, options.optimize, e_patterns)
File "/usr/bin/py3compile", line 154, in compile
for fn, versions_to_compile in filter_files(files, e_patterns, versions=
):
File "/usr/bin/py3compile", line 106, in filter_files
for fn in files:
File "/usr/share/python3/debpython/files.py", line 71, in filter_public
for fn in files:
File "/usr/share/python3/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-pil
dpkg: error while cleaning up:
le sous-processus script post-installation install=E9 a retourn=E9 une err=
eur de=20
sortie d'=E9tat 1
Des erreurs ont =E9t=E9 rencontr=E9es pendant l'ex=E9cution :
python3-pil:i386
Si quelqu'un peut m'aider ou m'indiquer une piste pour m'en sortir, je sera=
is=20
tr=E8s reconnaissant.
Philippe Merlin
P.S. Je remercie Etienne Mollier pour son message qui =E9tait tr=E8s int=E9=
ressant,=20
si j'avais lu le lien qu'il indique j'aurais certainement agis diff=E9remme=
nt,=20
malheureusement j'=E9tais d=E9j=E0 bien avanc=E9 dans ma migration et je ne=
pouvais=20
pas revenir en arri=E8re
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
=c3
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. Voici la sortie d'erreur : Suppression de python3-pil:i386 (4.0.0-4) ... dpkg-query: erreur: --listfiles requiert un nom de paquet légal. « python3-pil » ne l'est pas ; nom de paquet « python3-pil » ambigu avec plus d'une instance installée
Cette erreur se produit dans le script de pre-removal `prerm' extrait du paquet python3-pil_4.0.0-4_amd64.deb, script reproduit ci-dessous: #!/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 Aux écarts de versions près, le contenu ne devrait pas différer du code cité plus haut. Il faudrait relancer la moulinette `apt-get' après modification de ce script et voir comment la situation évolue. À plus, -- Étienne Mollier
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.
Voici la sortie d'erreur :
Suppression de python3-pil:i386 (4.0.0-4) ...
dpkg-query: erreur: --listfiles requiert un nom de paquet légal. « python3-pil » ne l'est pas ; nom de paquet « python3-pil » ambigu avec plus d'une instance installée
Cette erreur se produit dans le script de pre-removal `prerm'
extrait du paquet python3-pil_4.0.0-4_amd64.deb, script
reproduit ci-dessous:
#!/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
Aux écarts de versions près, le contenu ne devrait pas différer
du code cité plus haut. Il faudrait relancer la moulinette
`apt-get' après modification de ce script et voir comment la
situation évolue.
À plus,
--
Étienne Mollier <etienne.mollier@mailoo.org>
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. Voici la sortie d'erreur : Suppression de python3-pil:i386 (4.0.0-4) ... dpkg-query: erreur: --listfiles requiert un nom de paquet légal. « python3-pil » ne l'est pas ; nom de paquet « python3-pil » ambigu avec plus d'une instance installée
Cette erreur se produit dans le script de pre-removal `prerm' extrait du paquet python3-pil_4.0.0-4_amd64.deb, script reproduit ci-dessous: #!/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 Aux écarts de versions près, le contenu ne devrait pas différer du code cité plus haut. Il faudrait relancer la moulinette `apt-get' après modification de ce script et voir comment la situation évolue. À plus, -- Étienne Mollier
=c3
Bonsoir Philippe, On 05/14/2017 12:37 PM, MERLIN Philippe wrote:
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.
Je n'ai guère que deux conjectures en tête dans ce cas : 1. Soit le problème est lié au multi arch et un ou plusieurs paquets i386 associés de prêt ou de loin à PAM ou KDM marchent sur les pieds du paquet homologue en amd64. (ConsoleKit?) 2. Soit le problème est bel et bien lié à la configuration de PAM, qui donc serait à revoir, voir à remettre à zéro si applicable, ce que laisse particulièrement penser le symptôme de Sddm. À tout hasard, jette également un œil dans le journal de Xorg : /var/log/Xorg.0.log
Voilà ou j'en suis de ma migration et étant actuellement loin du poste incriminé, je ne peux continuer mes recherches.
Difficile effective de poursuivre sans avoir la machine à portée de main. :) Bon courage pour la fin de la migration -- Étienne Mollier
Bonsoir Philippe,
On 05/14/2017 12:37 PM, MERLIN Philippe wrote:
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.
Je n'ai guère que deux conjectures en tête dans ce cas :
1. Soit le problème est lié au multi arch et un ou plusieurs
paquets i386 associés de prêt ou de loin à PAM ou KDM
marchent sur les pieds du paquet homologue en amd64.
(ConsoleKit?)
2. Soit le problème est bel et bien lié à la configuration de
PAM, qui donc serait à revoir, voir à remettre à zéro si
applicable, ce que laisse particulièrement penser le symptôme
de Sddm.
À tout hasard, jette également un œil dans le journal de Xorg :
/var/log/Xorg.0.log
Voilà ou j'en suis de ma migration et étant actuellement loin
du poste incriminé, je ne peux continuer mes recherches.
Difficile effective de poursuivre sans avoir la machine à portée
de main. :)
Bon courage pour la fin de la migration
--
Étienne Mollier <etienne.mollier@mailoo.org>
Bonsoir Philippe, On 05/14/2017 12:37 PM, MERLIN Philippe wrote:
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.
Je n'ai guère que deux conjectures en tête dans ce cas : 1. Soit le problème est lié au multi arch et un ou plusieurs paquets i386 associés de prêt ou de loin à PAM ou KDM marchent sur les pieds du paquet homologue en amd64. (ConsoleKit?) 2. Soit le problème est bel et bien lié à la configuration de PAM, qui donc serait à revoir, voir à remettre à zéro si applicable, ce que laisse particulièrement penser le symptôme de Sddm. À tout hasard, jette également un œil dans le journal de Xorg : /var/log/Xorg.0.log
Voilà ou j'en suis de ma migration et étant actuellement loin du poste incriminé, je ne peux continuer mes recherches.
Difficile effective de poursuivre sans avoir la machine à portée de main. :) Bon courage pour la fin de la migration -- Étienne Mollier