# Python, portage, la saga (résolu)

## Saturne

Bonjour,

Wahou, ça faisait un bail que j'avais pas posté par ici  :Smile:  je regrette de ne pas avoir tellement le temps...

Bon du coup vous vous doutez que si je poste, c'est parce que je cale.

Vous vous souvenez peut-être de la vague de problèmes avec python, il y a quelques années, à l'arrivée de python-wrapper. On retrouve tous ces posts (et, malheureusement, seulement eux) en faisant une recherche sur mon problème, qui est le suivant :

```
Morgane ~ # portageq 

/usr/bin/portageq: ligne5: from : commande introuvable

/usr/bin/portageq: ligne10: try: : commande introuvable

/usr/bin/portageq: ligne12: Erreur de syntaxe près du symbole inattendu « ( »

/usr/bin/portageq: ligne12: `   def exithandler(signum, frame):'
```

La même erreur se produit avec emerge (y compris emerge --info), env-update, revdep-rebuild, bref les classiques quoi. Quant aux vieux posts qui parlent de ces erreurs, il me semble que leur solution (détruire le lien vers le wrapper, pour le remplacer par un lien direct vers l'exécutable de la bonne version) est carrément obsolète, même dans un cas désespéré (et de toute façon ça marche avec le wrapper, cf ci-dessous).

Aucune idée sur les causes possibles : récemment, j'ai passé cet ordi à systemd, sans problème autre que NetworkManager qui ne semble plus du tout fonctionner, après avoir un peu tatonné dans le noyau quand même. Je ne vois pas très bien en quoi ce serait lié, mais j'ai fait pas mal de recompilations à cette occasion et il a pu y avoir une mise à jour qui a mis le bazar.

Évidemment la première chose à laquelle j'ai pensé, c'est que j'avais cassé Python d'une façon où d'une autre. Actuellement :

```
Morgane ~ # eselect python list

Available Python interpreters:

  [1]   python2.6

  [2]   python2.7 *

  [3]   python3.2

  [4]   python3.3
```

Rien de très original. J'ai donc réinstallé python à la main, sauf que le problème persiste. Pourtant, les liens entre les différents exécutables et le wrapper sont bien en place, et python lui-même semble fonctionner correctement :

```
Morgane ~ # python2

Python 2.7.5 (default, Nov  9 2013, 18:39:45) 

[GCC 4.7.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> exit()

Morgane ~ # python3

Python 3.3.2 (default, Nov  9 2013, 19:49:55) 

[GCC 4.7.3] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> exit()
```

Je vous passe les détails, mais il me fait bien tout ce que je lui demande et le wrapper renvoie bien vers les bonnes versions (exécuter "python" renvoie sur python 2.7.5, comme indiqué par eselect). J'ai alors pensé que c'était portage et non python qui était peut-être cassé, et j'ai donc réinstallé portage (2.2.1) également à la main. Toujours sans résultat.

Du coup, je ne sais plus trop dans quelle direction chercher. Si vous avez des idées, je suis preneur ! je vous fournirai toutes les infos que vous voulez  :Smile: 

Ah, une petite note sur GCC 4.7 : a priori, pas de problème avec lui, j'ai identifié les paquets qui ne veulent pas du lto et jusqu'ici je n'ai guère eu de surprises, je serais surpris que ce soit lié...Last edited by Saturne on Sun Nov 17, 2013 4:16 pm; edited 1 time in total

----------

## guilc

As-tu lue la dernière news sur python-exec ? à priori, je pense que c’est le coupable !

|

V

----------

## Saturne

Ah, intéressant comme hypothèse. Je lis systématiquement les news quand elles me sont signalées ; je ne me souviens pas d'une news sur python-exec, mais bien entendu elle a pu m'échapper.

Du coup je découvre que :

```
Morgane ~ # eselect news list

News items:

  (none found)   
```

Du coup :

```
Morgane ~ # cat /usr/portage/metadata/news/2013-0

2013-02-10-new-13-profiles/

2013-02-10-new-13-profiles-server/

2013-03-29-udev-upgrade/

2013-04-10-baselayout-1-deprecation-final-warning/

2013-06-01-mysql-pbxt-dropped/

2013-06-07-portage-preserve-libs-default/

2013-06-30-cups16/

2013-08-07-vanilla-sources-stablization-policy/

2013-08-23-emerge-language/

```

Ce sont les dernières news que j'ai. J'ai vérifié 2012 au cas où, mais rien sur python-exec.

En regardant en ligne je vois bien une news mais datée du 6/11. Pour ma part, j'ai bien dev-python/python-exec mais pas dev-lang/python-exec (arbre de portage non mis à jour depuis le changement, donc). Je ne vois donc pas de raison qu'il y ait un problème. Par acquis de conscience je l'ai réinstallé mais toujours rien...  :Sad: 

----------

## guilc

```
$ cat /usr/portage/metadata/news/2013-11-07-python-exec-package-move/2013-11-07-python-exec-package-move.en.txt 

Title: python-exec package move

Author: Michał Górny <mgorny@gentoo.org>

Content-Type: text/plain

Posted: 2013-11-07

Revision: 1

News-Item-Format: 1.0

Display-If-Installed: dev-python/python-exec

Due to the recent issues which caused dev-python/python-exec:0 to be 

removed prematurely [1], we had to perform an urgent package move.

Since we could not use the automatic updates support in portage, users

will notice two python-exec packages and possibly blockers.

Currently, dev-lang/python-exec is the real package that contains

python-exec and that will be used in the future. dev-python/python-exec

is a virtual package that is kept for compatibility with dependencies

in already-installed packages.

In the most favorable scenario, the package will be upgraded correctly

on your next world update if you use the '--deep' (-D) and '--update'

(-u) options. If you don't want to perform a complete world update

or if it fails for you, you may as well manually upgrade

dev-python/python-exec:

  emerge -1 dev-python/python-exec

This will cause portage to update both python-exec packages and resolve

the blockers properly.

Please note that if you have applied any kind of package-specific

modifications to dev-python/python-exec (such as applying keywords

through 'package.accept_keywords'), you will need to copy them to 

dev-lang/python-exec as well.

If you have applied keywords to dev-python/python-exec in order

to unmask Python 3.3 on a stable system, please consider removing

the keywords and reading our wiki page that explains how to properly

unmask USE flags [2].

We apologize for all the inconveniences. If you have any more issues

with python-exec, please do not hesitate to contact as at #gentoo-python

IRC channel (@freenode) or the gentoo-python@lists.gentoo.org mailing

list.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=489440

[2]:https://wiki.gentoo.org/wiki/Unmasking_non-stable_Python_implementations

```

La news est récente, mais le souci est plus vieux (cf le bug #489440). Il y a souci au passage python-exec:0 à python-exec:2.

La solution si c’est ça le souci est d’émerger python-exec:0, ou d’upgrader pour avoir les nouveaux packages installant la rétrocompatibilité

L’autre solution qui a marché chez moi est de rebuilder tous les packages python pour qu’ils utilisent le nouveau wrapper à l’install, mais si portage est flingué, c’est pas évident…

----------

## Saturne

Oui j'ai vu la news en ligne du coup. Le problème c'est effectivement que portage est mort. 

En regardant bugzilla, je vois que ça date de fin octobre : ça reste récent. J'aurais dû préciser que je n'ai pas touché cet ordi depuis environ un mois (boulot oblige). Du coup je ne devrais pas avoir été affecté par quoi que ce soit qui se soit produit depuis début octobre.

Néanmoins, si le problème vient bien de là, je ne sais pas trop quoi faire. Je ne peux même pas mettre à jour l'arbre de portage.

J'essaie de me souvenir de ce que j'ai bien pu faire pour casser tout ça, mais il n'y a rien eu de spécial qui m'ait marqué :/

----------

## Saturne

Bon j'insiste un peu mais ce problème me prend sérieusement la tête (sans compter qu'il rend toute mise à jour très compliquée).

Donc, je sais que le responsable n'est pas portage que j'ai réinstallé plusieurs fois (jusqu'à le pousser en 2.2.7).

A priori Python fonctionne bien.

La preuve c'est que je récupère Portage, à condition de l'exécuter via python (python /usr/bin/portage --info). Certains paquets passent, d'autres non (portage lui même, python-exec échoue aussi pour une histoire d'eapi, je regarderai plus tard). Impossible de recourir à revdep-rebuild ou python-updater qui sont bien des scripts bash, mais qui ont besoin de portageq.

Après avoir épuisé les vieux fils en français et en anglais (malheureusement rien de très récent sur ces erreurs), je suis passé à l'allemand et j'ai trouvé ça (https://forums.gentoo.org/viewtopic-p-7433320.html?sid=b2b5ca3c5c3fae6a5c2a1429cc36eb3e).

Et là, tada... CONFIG_BINMFT_SCRIPT est à N dans mon noyau !

Je ne me souviens pas de cette option, elle est nouvelle ? En tous cas, elle n'aurait jamais dû m'échapper...

Edit : après reboot, ça remarche, ouf. C'était vraiment complètement idiot comme problème, j'aurais pas cru que ça viendrait du noyau.

J'ai tout détaillé ici parce que je ne déteste rien de plus qu'un fil qui meurt sans avoir livré sa solution  :Smile: 

----------

## guilc

Arf oui, j’aurais pas pensé à ça. Je suis même étonné que le système boote sans !

C’est effectivement une nouvelle option apparue récemment (3.10 ou 3.11, me rappelle plus) qui a été introduite visiblement pour l’embarqué.

Content que tu ais trouvé !

----------

## kopp

C'est quoi cette option ? Elle n'apparait pas dans ma config du noyau, pas de retour pour une recherche dans menuconfig ?

----------

## guilc

Y a une typo dans le nom  :Wink: 

http://cateee.net/lkddb/web-lkddb/BINFMT_SCRIPT.html Apparu en 3.10

----------

## kopp

Ce qui explique pourquoi je ne trouvais rien non plus dans google   :Embarassed: 

J'aurais pu lire... enfin, scanner le topic en teuton pour voir...

Bon, c'est un HS, mais puisque la question originale est résolue : à quoi ça sert de désactiver ce genre de chose ? Sécurité ? Taille du noyau ?

----------

