Ca fait deux heures que je cherche un moyen de savoir la version de gcc
qui a =E9t=E9 utilis=E9e =E0 la compilation d'un pkg donn=E9...
J'ai questionn=E9 les chans IRC gentoo et gcc et personne n'a su me
dire...=20
J'avais =E9videmment penser d=E8s le depart =E0 un gros grep bourrin
sur /var/db/pkgs/*/* mais j'avais pas capt=E9 que l=E0 o=F9 on peux trouver=
le
max d'infos, c'=E9tait bzipp=E9... qd je m'en suis apercu grace a un gars d=
e
l'irc de #gentoo-hardened, je me suis jet=E9 sur mon bash et 3min plus
tard, voil=E0 mon micro script bash d'une ligne:
# for x in /var/db/pkg/*/* ; do echo `echo $x | sed -e "s/^.*pkg\///g"`
" " gcc-`bunzip2 -c $x/environment.bz2 | grep "^PATH" | sed -e
"s/^.*gcc-bin\///" | sed -e "s/:.*$//"`; done
et voil=E0 :o) ... maintenant on peux tester les gcc slott=E9s
tranquillement et savoir ce que l'on a emerger et comment :)
TuTTle
PS: Si vous avez une optimisation, je suis preneur pour mettre dans mon
alias...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.2.3">
</HEAD>
<BODY>
Bonjour<BR>
<BR>
Ca fait deux heures que je cherche un moyen de savoir la version de g=
cc qui a été utilisée à la compilation d'un pkg donn=
33;...<BR>
J'ai questionné les chans IRC gentoo et gcc et personne n'a su me dire=
... <BR>
J'avais évidemment penser dès le depart à un gros grep bourr=
in sur /var/db/pkgs/*/* mais j'avais pas capté que là où on =
peux trouver le max d'infos, c'était bzippé... qd je m'en suis ap=
ercu grace a un gars de l'irc de #gentoo-hardened, je me suis jeté sur=
mon bash et 3min plus tard, voilà mon micro script bash d'une ligne:<=
BR>
<BR>
<H1>
# for x in /var/db/pkg/*/* ; do echo `echo $x | sed -e "s/^.*pkg\///g&=
quot;` " " gcc-`bunzip2 -c $x/environment=
.bz2 | grep "^PATH" | sed -e "s/^.*gcc-bin\///" |=
sed -e "s/:.*$//"`; done
</H1>
<BR>
et voilà :o) ... maintenant on peux tester les gcc slottés =
tranquillement et savoir ce que l'on a emerger et comment :)<BR>
<BR>
<BR>
TuTTle<B=
R>
<BR>
<BR>
PS: Si vous avez une optimisation, je suis preneur pour mettre dans m=
on alias...<BR>
<BR>
</BODY>
</HTML>
--=-1c7m9c1UhT52l2Ss4H06--
--=-kxvaIVnB+dTsqLRxBbdL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
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
Pascal BERTIN
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
-- mailing list
Bonjour,
je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais
je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du
genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre :
! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le
packet bloquant alors que la version (n+2) de D existe et est stable (en
fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)?
2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
Comme le problème est résolu, c'est pas très grave, mais ça serait
pratique, et je ne comprends pas que la mise à jour n'ai jamais été
proposée.
(pour info,
A = oppenoffice-bin
B = emul-linux-x86-xlibs
C = xorg-x11)
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
