# [crossdev] lanciare emerge [risolto... forse]

## cloc3

```

PORTAGE_CONFIGROOT=/mnt/chroot/udoo ROOT=/mnt/chroot/udoo SYSROOT=/mnt/chroot/udoo nohup emerge @system --autounmask-write y

...

s939 ~ # ls -l /etc/portage/package.keywords/ -lAt|grep cfg

-rw-r--r-- 1 root root  775 26 dic 21.52 ._cfg0000_zzz

```

come mail il file di smascheramento viene creato in /etc/portage, anzichè in /mnt/chroot/udoo/etc/portage come dovrebbe?

ho già verificato che la compilazione dei pacchetti, al contrario, avviene correttamente nel ramo giusto.

è un baco marchiano di emerge, oppure c'è qualche cosa di sbagliato nel mio comando?

----------

## djinnZ

Mai tentato di usare varieROOT=vettelappesca emerge per altro che non fossero i pacchetti binari (e non di recente) ma... mi sa che ti tocca aprire un bug.

Ed è grosso come una casa. Per averne la prova basta che fai il merge della nuova conf che ti ritrovi e vedi se considera lo smascheramento.

A leggere sté cose... quasi mi vien di passare a paludis.

----------

## cloc3

ho trovato un baco qui.

però è datato al mese di maggio, e secondo me, non era documentato bene, al punto che è stato ignorato del tutto.

allora ho preferito aprire un baco indipendente. alla faccia della netiquette  :Smile: .

ho anche provato a suggerire un grado di gravità superiore al normale.

volevo addirittura indicarlo come critico, in quanto bloccante delle attività di sviluppo, ma mi sembrava di non potermi permettere un simile giudizio.

se tuttavia pensate che il problema abbia una propria serietà (è mai possibile che il cross_compiling per l'embedding sia così poco usato dagli utenti gentoo?), provate a votare il baco per promuovere una rapida soluzione.

----------

## djinnZ

UFFA! Lo hanno assegnato come errore di autounmask.

Potresti provare la verifica che ti ho suggerito?

Se è solo autounmask che va a scrivere nel percorso sbagliato è un comune baco (può capitare) ma se, come sospetto, emerge considera /etc/portage e non /CONFIGROOT/etc/portage per calcolare smascheramenti e dipendenze la cosa è molto seria.

Dato che ad oggi ho usato CONFIGROOT&C solo per clonare sistemi identici (l'unica differenza erano le CFLAGS, per il resto /etc/portage era identica visto che non facevo altro che copiarla) od in ciclo con --nodeps tanto per rimpiazzare una toolchain danneggiata non ho modo di verificare. Tu ha già due sistemi difformi, io li dovrei creare ex novo.

----------

## cloc3

 *djinnZ wrote:*   

> UFFA! Lo hanno assegnato come errore di autounmask.
> 
> Potresti provare la verifica che ti ho suggerito?
> 
> 

 

penso di avere fatto qualcosa di più.

ho allegato l'output di strace.

un programma, se vuole tenere conto dei contenuti di ${PORTAGE_CONGIFROOT}, deve quantomeno guardarci dentro.

se accede esclusivamente alla /etc/portage di default, si capisce facilmente cosa stia facendo.

in effetti, è sembrato strano anche a me che il bug wrangler abbia trattato in questo modo il bug.

potrebbe essere semplicemente una mossa provvisoria, o può essere che, il giorno di Santo Stefano, fosse un po' stanco e non abbia letto con attenzione lo strace.

zd ogni buon conto, ho replicato con l'inglese che posso.

adesso vediamo cosa ne dice Zac Medico.

spero che qualche altro utente si interessi a questo bug, per fare un po' di pressione terapeutica.

----------

## cloc3

navigando nel forum, ho trovato questa strada per fare il cross-compiling di un sistema completo.

mi sembra però ancora un percorso faticoso che non ho interesse a provare in questo momento.

----------

## djinnZ

 *cloc3 wrote:*   

> penso di avere fatto qualcosa di più.
> 
> ho allegato l'output di strace.

 e secondo te sotto le feste lo guardano?  :Shocked:   :Question: 

Per come lo hai documentato sembra che sia semplicemente la routine dell'autounmask a scantonare.

Il problema è che proprio GenOne mi è sempre parso un tantino "distratto" nei confronti del supporto ai binari ed al cross compiling. Di qui la battutaccia sul passare a paludis.

----------

## cloc3

 *djinnZ wrote:*   

>  *cloc3 wrote:*   penso di avere fatto qualcosa di più.
> 
> ho allegato l'output di strace. e secondo te sotto le feste lo guardano?  
> 
> Per come lo hai documentato sembra che sia semplicemente la routine dell'autounmask a scantonare.
> ...

 

purtroppo faccio molta fatica a espirmermi in inglese, uso giri di parole di dubbia efficacia, e alla fine scrivo cose che corrispondono parzialmente alle mie idee.

comunque ZacMedico non solo mi ha ascoltato, ma mi ha anche dato una risposta con qualche spiegazione.

il mio baco, adesso, è stato marcato come duplicato (c'era da attenderselo), ma ha dato origine a  sviluppi costruttivi.

davvero, a quanto pare, il supporto al cross-compiling è cosa complessa per Gentoo, ma penso che non sia per capriccio: il problema è tosto.

tuttavia, una distribuzione dovrebbe apparire un po' più trasparente ai propri utenti.

sinceramente, non ho capito del tutto la spiegazione di ZacMedico sul comportamento standard (by design) di PORTAGE_CONFIGROOT.

se chiedo di installare su un percorso alternativo è necessario che emerge ci guardi dentro, altrimenti non si potrà ottenere nulla di coerente.

ho fatto anche una prova con l'uso di --root-deps. il primo tentativo mi ha dato questa risposta:

```

!!! '/mnt/chroot/udoo' does not start with $EROOT.

```

non ha rilievo il comando che io possa avere lanciato (sicuramente avrò stracapito qualcosa).

il problema è che $EROOT non è una variabile documentata né in man emerge, né in man portage e tanto meno in man make.conf.

----------

## cloc3

alla fine ho capito.

cioè, non ho capito cosa vuol dir $EROOT, ma ho capito come si usa correttamente l'opzione --root-deps  :Rolling Eyes:  .

```

PORTAGE_CONFIGROOT=/usr/armv7a-hardfloat-linux-gnueabi ROOT=/usr/armv7a-hardfloat-linux-gnueabi SYSROOT=/usr/armv7a-hardfloat-linux-gnueabi nohup emerge @system --root-deps=rdeps

```

e, chissa mai, forse ho risolto...

viva gentoo.

 :Smile: 

----------

## cloc3

risolto ... forse   :Question: 

perché, forse???

forse perché:

```

 * The following 58 packages have failed to build or install:

 * 

 *  (sys-devel/gcc-4.8.4:4.8/4.8::gentoo, ebuild scheduled for merge to '/usr/armv7a-hardfloat-linux-gnueabi/'), Log file:

 *   '/mnt/chroot/root32/udoo/tmp/ramtmp/arm/portage/sys-devel/gcc-4.8.4/temp/build.log'

 *  (dev-lang/perl-5.20.1-r4:0/5.20::gentoo, ebuild scheduled for merge to '/usr/armv7a-hardfloat-linux-gnueabi/'), Log file:

 *   '/mnt/chroot/root32/udoo/tmp/ramtmp/arm/portage/dev-lang/perl-5.20.1-r4/temp/build.log'

 *  (app-admin/perl-cleaner-2.19:0/0::gentoo, ebuild scheduled for merge to '/usr/armv7a-hardfloat-linux-gnueabi/')

...

```

questo fa parte del gioco.

un po' me l'aspettavo.

durante la compilazione, accadono cose come queste:

```

/bin/sh: ./try: cannot execute binary file

The program compiled OK, but exited with status 126.

```

(dev-lang/perl)

è colpa di portage, è colpa di emerge, è colpa dell'ebuild, è colpa del makefile upstream?

forse un po' tutte queste le cose. a quanto pare il cross compiling, in gentoo, è di certo su una buona strada, ma ancora da venire, per noi semplici utenti.

----------

