!!! ERROR: sys-devel/automake-wrapper-3-r1 failed.
!!! Function dyn_unpack, Line 669, Exitcode 1
!!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work'
!!! If you need support, post the topmost build error, NOT this status message.
Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et
que /var/portage-extra est servi en NFS (par une machine NetBSD). Le
problème est sans doute là mais je ne vois pas où puisque la machine
NetBSD exporte avec :
!!! ERROR: sys-devel/automake-wrapper-3-r1 failed. !!! Function dyn_unpack, Line 669, Exitcode 1 !!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work' !!! If you need support, post the topmost build error, NOT this status me ssage.
Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et que /var/portage-extra est servi en NFS (par une machine NetBSD). Le problème est sans doute là mais je ne vois pas où puisque la machin e NetBSD exporte avec :
Et que, je l'ai montré, root sur la machine gentoo peut bien créer le s répertoires qu'il veut.
Salut,
le problème vient justement du lien je pense... Tu as beau être root, il est probable que portage soit lancé en mode user et même si ce n'était pas le cas, SANDBOX est là pour veiller à ce qu'il ne fasse pas de bêtises. Dans ton cas il me semble que le lien symbolique déroute un peu sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il doit s'apercevoir que /var/tmp/portage est en fait /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien symbolique !
!!! ERROR: sys-devel/automake-wrapper-3-r1 failed.
!!! Function dyn_unpack, Line 669, Exitcode 1
!!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work'
!!! If you need support, post the topmost build error, NOT this status me ssage.
Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et
que /var/portage-extra est servi en NFS (par une machine NetBSD). Le
problème est sans doute là mais je ne vois pas où puisque la machin e
NetBSD exporte avec :
Et que, je l'ai montré, root sur la machine gentoo peut bien créer le s
répertoires qu'il veut.
Salut,
le problème vient justement du lien je pense... Tu as beau être root,
il est probable que portage soit lancé en mode user et même si ce
n'était pas le cas, SANDBOX est là pour veiller à ce qu'il ne fasse
pas de bêtises.
Dans ton cas il me semble que le lien symbolique déroute un peu
sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
doit s'apercevoir que /var/tmp/portage est en fait
/var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !
!!! ERROR: sys-devel/automake-wrapper-3-r1 failed. !!! Function dyn_unpack, Line 669, Exitcode 1 !!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work' !!! If you need support, post the topmost build error, NOT this status me ssage.
Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et que /var/portage-extra est servi en NFS (par une machine NetBSD). Le problème est sans doute là mais je ne vois pas où puisque la machin e NetBSD exporte avec :
Et que, je l'ai montré, root sur la machine gentoo peut bien créer le s répertoires qu'il veut.
Salut,
le problème vient justement du lien je pense... Tu as beau être root, il est probable que portage soit lancé en mode user et même si ce n'était pas le cas, SANDBOX est là pour veiller à ce qu'il ne fasse pas de bêtises. Dans ton cas il me semble que le lien symbolique déroute un peu sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il doit s'apercevoir que /var/tmp/portage est en fait /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien symbolique !
On Thu, Feb 15, 2007 at 09:00:47AM +0100, Boris Fersing wrote a message of 100 lines which said:
Dans ton cas il me semble que le lien symbolique déroute un peu sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il doit s'apercevoir que /var/tmp/portage est en fait /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme ("sandbox" ?), programmé dans portage, qui l'en empêche, c'est cela ?
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien symbolique !
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre cela automatiquement en place au démarrage. -- mailing list
On Thu, Feb 15, 2007 at 09:00:47AM +0100,
Boris Fersing <kernelsensei@gentoo.org> wrote
a message of 100 lines which said:
Dans ton cas il me semble que le lien symbolique déroute un peu
sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
doit s'apercevoir que /var/tmp/portage est en fait
/var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme
("sandbox" ?), programmé dans portage, qui l'en empêche, c'est cela ?
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre
cela automatiquement en place au démarrage.
--
gentoo-user-fr@gentoo.org mailing list
On Thu, Feb 15, 2007 at 09:00:47AM +0100, Boris Fersing wrote a message of 100 lines which said:
Dans ton cas il me semble que le lien symbolique déroute un peu sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il doit s'apercevoir que /var/tmp/portage est en fait /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme ("sandbox" ?), programmé dans portage, qui l'en empêche, c'est cela ?
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien symbolique !
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre cela automatiquement en place au démarrage. -- mailing list
Boris Fersing
Le 15/02/07, Stephane Bortzmeyer a écrit :
On Thu, Feb 15, 2007 at 09:00:47AM +0100, Boris Fersing wrote a message of 100 lines which said:
> Dans ton cas il me semble que le lien symbolique déroute un peu > sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il > doit s'apercevoir que /var/tmp/portage est en fait > /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme ("sandbox"?), programmé dans portage, qui l'en empêche, c'est cela ?
En fait quand portage compile une application, il le fait dans un environement protégé, sous surveillance, Sandbox. Si portage essaye d'accéder à un fichier en dehors de cet environnement, ça gueule ! C'est pour éviter qu'un ebuild / makefile mal foutu casse ton système !
Boris.
> Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien > symbolique !
Ça marche, merci beaucoup :
digory:/var/tmp % sudo mkdir portage digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/porta ge
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre cela automatiquement en place au démarrage. -- mailing list
Le 15/02/07, Stephane Bortzmeyer<stephane@sources.org> a écrit :
On Thu, Feb 15, 2007 at 09:00:47AM +0100,
Boris Fersing <kernelsensei@gentoo.org> wrote
a message of 100 lines which said:
> Dans ton cas il me semble que le lien symbolique déroute un peu
> sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
> doit s'apercevoir que /var/tmp/portage est en fait
> /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme
("sandbox"?), programmé dans portage, qui l'en empêche, c'est cela ?
En fait quand portage compile une application, il le fait dans un
environement protégé, sous surveillance, Sandbox. Si portage essaye
d'accéder à un fichier en dehors de cet environnement, ça gueule !
C'est pour éviter qu'un ebuild / makefile mal foutu casse ton système
!
Boris.
> Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
> symbolique !
Ça marche, merci beaucoup :
digory:/var/tmp % sudo mkdir portage
digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/porta ge
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre
cela automatiquement en place au démarrage.
--
gentoo-user-fr@gentoo.org mailing list
On Thu, Feb 15, 2007 at 09:00:47AM +0100, Boris Fersing wrote a message of 100 lines which said:
> Dans ton cas il me semble que le lien symbolique déroute un peu > sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il > doit s'apercevoir que /var/tmp/portage est en fait > /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !
Il a le droit au sens Unix mais il y a un autre mécanisme ("sandbox"?), programmé dans portage, qui l'en empêche, c'est cela ?
En fait quand portage compile une application, il le fait dans un environement protégé, sous surveillance, Sandbox. Si portage essaye d'accéder à un fichier en dehors de cet environnement, ça gueule ! C'est pour éviter qu'un ebuild / makefile mal foutu casse ton système !
Boris.
> Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien > symbolique !
Ça marche, merci beaucoup :
digory:/var/tmp % sudo mkdir portage digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/porta ge
Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre cela automatiquement en place au démarrage. -- mailing list
Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ? Ça me semble plus dans la philosophie portage, et plus simple à mettre en oeuvre.
-- Christophe PEREZ -- mailing list
Le Thu, 15 Feb 2007 09:09:18 +0100, Stephane Bortzmeyer a écrit :
Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !
Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir le
PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?
Ça me semble plus dans la philosophie portage, et plus simple à mettre
en oeuvre.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ? Ça me semble plus dans la philosophie portage, et plus simple à mettre en oeuvre.
-- Christophe PEREZ -- mailing list
Stephane Bortzmeyer
On Thu, Feb 15, 2007 at 09:58:56AM -0400, Christophe PEREZ wrote a message of 17 lines which said:
Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?
Ah, oui, je l'ai mis dans mon /etc/make.conf (en variable d'environnement, elle semble ignorée) et ça marche. Merci beaucoup.
-- mailing list
On Thu, Feb 15, 2007 at 09:58:56AM -0400,
Christophe PEREZ <christophe.perez@novazur.com> wrote
a message of 17 lines which said:
Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir
le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?
Ah, oui, je l'ai mis dans mon /etc/make.conf (en variable
d'environnement, elle semble ignorée) et ça marche. Merci beaucoup.
