# [Emerge] Plus rien ne compile

## SiOu

VOila depuis peu, plus aucun package ne compile avec une erreur identique pour tous, en voici un exemple :

 *Quote:*   

> >>> Emerging (1 of 1) sys-apps/portage-2.1.6.13
> 
>  * portage-2.1.6.13.patch.bz2 RMD160 SHA1 SHA256 size  ...            [ ok ]
> 
>  * portage-2.1.6.tar.bz2 RMD160 SHA1 SHA256 size  ...                 [ ok ]
> ...

 

Le build log du package :

 *Quote:*   

>  ^[[31;01m*^[[0m
> 
>  ^[[31;01m*^[[0m ERROR: sys-apps/portage-2.1.6.13 failed.
> 
>  ^[[31;01m*^[[0m Call stack:
> ...

 

Voici mon emerge --info :

 *Quote:*   

> Gentoo siou # emerge --info
> 
> Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.2.4, glibc-2.10.1-r0, 2.6.26-gentoo-r1 x86_64)
> 
> =================================================================
> ...

 

Je ne vois pas ce que je puisse faire la. Ca faisait un moment que j'avais pas eu ce type de problème ( ca fait 6 ans que je suis sous gentoo .. ).

Merci d'avance.

----------

## elyes

salut,

je pense a la piste de python 3.1

assures toi que cette version ne soit pas utilisée, portage ne l'aime pas pour l'instant.

Cordialement,

Elyes

----------

## SiOu

 *Quote:*   

> Gentoo siou # eselect python list
> 
> Available python interpreters:
> 
>   [1]   python2.4
> ...

 

Non ca vient pas de la malheureusement  :Sad: 

----------

## netfab

Hello,

Peux-tu poster :

```

# cat /etc/make.conf

# cat /var/tmp/portage/sys-apps/portage-2.1.6.13/temp/environment

```

----------

## SiOu

 *Quote:*   

> Gentoo siou # cat /etc/make.conf 
> 
> # These settings were set by the catalyst build script that automatically built this stage
> 
> # Please consult /etc/make.conf.example for a more detailed example
> ...

 

 *Quote:*   

> Gentoo siou # cat /var/tmp/portage/sys-apps/portage-2.1.6.13/temp/environment
> 
> Gentoo siou # cat /var/tmp/portage/sys-apps/portage-2.1.6.13/temp/environment.filtered 
> 
> 

 

Les deux sont vierges ~~[/code]

----------

## xaviermiller

Salut,

As-tu fait un python_updater après avoir passé à la version 2.6 ?

En tous cas, évite de passer à la 3.1 c'est pas bon, rien ne marche  :Wink: 

----------

## netfab

Désactive tes overlays, réinstalle portage manuellement, et essaye un emerge portage.

Tu peux aussi vider le répertoire /var/tmp/portage/ et vérifier que le système de fichier ne contient pas d'erreur, et que son montage se fait correctement.

----------

## SiOu

J'ai fait un python updater, mais sans succée puisque je ne peux rien compiler ..

J'ai ensuite réinstallé maunellement portage, sans effet. 

Je commence a craindre le pire !

----------

## SiOu

Aunce idée ?!  :Sad: 

----------

## Biloute

 *SiOu wrote:*   

>  *Quote:*   Gentoo siou # eselect python list
> 
> Available python interpreters:
> 
>   [1]   python2.4
> ...

 

Quelque part tu as 4 version de python alors que du devrais avoir que la v2.5 par défault. Ca viendrait peut-être de là non?

Est-ce que tu as essayé en remplacant la v2.6 par la v2.5 ?

----------

## SiOu

WHaouuu c'était ca ;... MERCIII !!

M'enfin ca commence a devenir n'importe quoi portage, pouvoir installer 2 versions de python qui ruine emerge en toute impunité ..

----------

## netfab

Tu es en ~arch. Portage fonctionne avec python 2.6 :

```

$ eselect python list

Available python interpreters:

  [1]   python2.6 *

```

Et, à priori, la fonction qui foire est une fonction bash.

----------

## xaviermiller

Oui, mais une fois le "eselect python set XXX", il faut faire "python_updater"  :Wink: 

----------

## SiOu

 *XavierMiller wrote:*   

> Oui, mais une fois le "eselect python set XXX", il faut faire "python_updater" 

 

Euhh oui, mais quand tu ne peux plus emerge, le python updater sert un peu a rien  :Very Happy: 

Sinon le probleme a été résolue sur la branche 2.6 de python ? et la 3.1 ?

----------

## xaviermiller

Surtout pas la 3.1 !!!

C'est une erreur fondamentale de l'avoir tild-arché... rien ne fonctionne en 3.1, la syntaxe a changé et n'est pas rétro-compatible.

----------

## Kazuya

Hello,

bah écoute si le python_updater ne fait rien chez toi, c'est bizarre, car moi tout fonctionne très bien avec la 2.6:

 *eselect python list wrote:*   

> 
> 
> Available python interpreters:
> 
>   [1]   python2.6 *
> ...

 

Comme tu peux le voir, je n'ai plus de traces de la v2.4 et v2.5... 

Je suis en ~amd64

----------

## xaviermiller

En tous cas, sur le forum principal (anglophone), ça hurlait pas mal à ce sujet, ces derniers jours.

Vérifie le lien symbolique /usr/bin/python, et son contenu.

----------

## fb99

le plus simple c'est de réparer portage manuellement http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml (attention il faut adapter à ta version de portage (eix -s portage), ensuite revdep-rebuild ou ton python-updater...

mes 0.02 cents

----------

## mrpouet

 *SiOu wrote:*   

> WHaouuu c'était ca ;... MERCIII !!
> 
> M'enfin ca commence a devenir n'importe quoi portage, pouvoir installer 2 versions de python qui ruine emerge en toute impunité ..

 

Ben disons que c'est pas évident à traiter car çà imposerait que portage-2.1.6.13 qui est full stable sur la pluspart des arch soit fonctionnel avec une version de python qui contient moins d'arch stabilisées:

```

Keywords: python-2.6.2-r1[2.6]: alpha amd64 arm m68k x86 ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86-fbsd 

```

```

Keywords: portage-2.1.6.13[0]: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86

```

de ce fait portage-2.1.16.13 ne pourrait pas être stable pour hppa, ia64, ppc, ppc64, s390, sh, sparc ce qui est balaud finalement.

secondo si tu fait en sorte que cette version soit fonctionnelle avec python-2.6 celà veut dire qu'on va devoir touché au code de portage-2.1.6.13, donc faire une revision bump et de ce fait le mettre en testing... ce qui implicitement donne plus de taffe aux arch teams... il y a aussi que portage-2.5 a beaucoup plus de maturité que la 2.6 (on parle d'un profile stable là, donc çà requit des paquet ayant pas mal de bouteille dans le main tree et ayant été beaucoup testé ).

La team portage bosse activement sur la 2.2 (d'ailleur la 2.1 est toujours maintenue ?) , enfin aprés je ne fais pas partie de la herd portage alors je ne peux pas te dire dans le détails mais je pense qu'ils doivent avoir un ensemble de raisons (le mieux serait d'envoyer un mail à zmedico et de lui demander poliment pourquoi)

----------

## SiOu

S'il n'y avait que python encore qui merdait ... udev-145 ... une blague lui aussi  :Very Happy: 

Impossible de démarrer la machine avec, fallut que je trouve un live-cd pour remettre une version antèrieure ! 

Le ~amd64, c'est plus ce que c'était faut le dir :/

----------

## Kazuya

Hello,

euh le ~amd64 fonctionne bien chez moi... (juste gegl qui merdouille et donc par conséquent pas encore de gimp 2.6.7 mais c'est tout...) 

Après il faut relativiser, on ne fait pas ses mises à jours de  ~amd64 comme pour la stable, et faut voire ce que l'on met à jour... 

<perso>

Si c'est pour passer d'une version de gimp-2.6.6 à gimp-2.6.7 oui tu peux lancer ta mises à jour tout en faisant ton travail à coté bien sur... mais pas quand il s'agit de baselayout/openrc ou d'autres programmes important comme ça, il faut prendre le temps de faire la mise à jour et être sur de ne pas faire de conneries histoire de garder une machine en état de marche ou de revenir très vite en arrière quand il s'agit d'une station de travail...

</perso>

----------

## mrpouet

 *SiOu wrote:*   

> S'il n'y avait que python encore qui merdait ... udev-145 ... une blague lui aussi 
> 
> Impossible de démarrer la machine avec, fallut que je trouve un live-cd pour remettre une version antèrieure ! 
> 
> 

 

euhh.. impossible de démarrer la machine mais encore ? t'avais pas un message ni rien ?

Tu verrai tout les trucs que l'on doit gérer... ya du taff  :Wink: 

----------

## SiOu

Je ne critique pas votre travail ! Loin dela ! Je trouve juste décevant que la branche ~ devienne le bac à essaie, meme si cela a toujours été le cas, et le but, jen suis conscient !

Mais la je ne comprends pas pourquoi python3-1 et udev-145 ne sont pas hardmasked !

Sinon concernant le package udev-145, il semblerait qu'il n'arrivait pas ouvrir les différents tty, et ne pouvait charger le module réseau et surment bien d'autres erreurs.

Puis une erreur fatal qui dit que udev n'a pu s'intialiser correctement, il me semble.

----------

## mrpouet

 *SiOu wrote:*   

> Je ne critique pas votre travail ! Loin dela ! Je trouve juste décevant que la branche ~ devienne le bac à essaie, meme si cela a toujours été le cas, et le but, jen suis conscient !
> 
> Mais la je ne comprends pas pourquoi python3-1 et udev-145 ne sont pas hardmasked !
> 
> Sinon concernant le package udev-145, il semblerait qu'il n'arrivait pas ouvrir les différents tty, et ne pouvait charger le module réseau et surment bien d'autres erreurs.
> ...

 

python3.1 et udev-145 on été masqués à titre d'informations  :Wink: 

concernant ton problême d'udev, il y a tout plein de message aprés l'emergé de udev dans le postinst() (la phase aprés la copie des fichiers sur /), les as tu lu ?

Ben le but d'une branche testing c'est de tester... comme tu le fais si bien remarqué

----------

## Mike Hunt

Et donc, qu'en est t-il, comme lu fut mentionné, du lien symbolique /usr/bin/python?

```
file /usr/bin/python
```

----------

