Re: Emulare make install senza scrivere file

2020-10-04 Per discussione cage
On Sun, Oct 04, 2020 at 03:52:47PM +0200, Alessandro Rubini wrote:

Ciao!!

Questo tuo messaggio contiene due  informazioni (su make e find) molto
utili oltre che a me sconosciute, grazie! :)

> Comunque si puo` sempre fare "make -n install". "-n" vuol dire "non farlo",

In particolare questa e' una soluzione  di uso piu' generale di quella
che avevo proposto io.

> Saluti
> /alessandro

Ciao!
C.



Re: Emulare make install senza scrivere file

2020-10-04 Per discussione Alessandro Rubini
> Se il sistema  di compilazione usa gli autootols potrebbe  fare al tuo
> caso la variabile DESTDIR

Vero. Il valore predefinito (se si usa "./configure" senza argomenti)
dovrebbe essere /usr/local. Quindi un "make install" non dovrebbe
modificare il sistema.

In gioventu` installavo molto in /usr/local, che e` di mia proprieta`.
Quindi "make install" non lo facevo da superutente, e se per caso (o
per baco) il pacchetto installa in /etc (oltre a /usr/local/bin
eccetera) ci si accorge perche` da` errore.

Comunque si puo` sempre fare "make -n install". "-n" vuol dire "non farlo",
ma vengono comunque mostrati i comandi che sarebbero stati eseguiti. A volte
si capisce dove andrebbe a scrivere, a volte no.

Infine, altro trucco d'epoca, dopo aver fatto per esempio "touch /tmp/stamp"
si puo` fare "make install" e poi "find / -xdev -newer /tmp/stamp" per sapere
tutti i file che sono stati scritti. Certo, se sovrascrive file di sistema,
il danno e` comunque fatto, anche se sappiamo quali.

Saluti
/alessandro



Re: Emulare make install senza scrivere file

2020-10-04 Per discussione cage
On Sat, Oct 03, 2020 at 11:55:54PM +0100, Antonio wrote:
> Salve,

Ciao!

>
> Vorrei lanciare make install ma senza che copia i file veramente.

[...]

>
> Suggerimenti?

Se il sistema  di compilazione usa gli autootols potrebbe  fare al tuo
caso la variabile DESTDIR

https://www.gnu.org/software/make/manual/html_node/DESTDIR.html#DESTDIR

Purtroppo si tratta solo di una convenzione e -come tale- non e' detto
che venga rispettata dal sistema  usato dagli autori del pacchetto che
ti interessa.

Se un file  "configure": esiste, e' uno script di  shell, il contenuto
appare come un guazzabuglio di lettere che fanno riferimento a sistemi
unix  in voga  nel  secolo scorso  :-) e  contiene  un riferimento  ad
autoconf in cima  allora probabilmente il programma  usa gli autotools
:)

Ciao!
C.



Re: Emulare make install senza scrivere file

2020-10-04 Per discussione Giancarlo Martini
devi aprire il file Makefile con un editor e cercare la parola install
all'inizio della riga, cosi
install:
nella riga sottostante ci dovrebbero essere anche i nomi dei file
interessati all'installazione


Il giorno dom 4 ott 2020 alle ore 00:56 Antonio  ha scritto:

> Salve,
>
> avevo problemi con la versione 0.96.5 del client bitcoin Armory in
> quanto nell'installare il pacchetto *.deb, cercava di sovrascrivere
> altri file e quindi apt falliva.
>
> Ho quindi deciso di compilare da sorgente il che mi e' riuscito. Lancio
> il client da dentro la directory di compilazione con "python
> ArmoryQt.py" ma sto considerando se installare con "make install". Il
> problema e' che cosi' mi rompe il sistema perché il file non verrebbero
> visti da APT.
>
> Vorrei lanciare make install ma senza che copia i file veramente. E'
> possibile? Magi poi cerco di capire quali sono i file e potrei cercare
> di creare un pacchetto *.deb anche se l'ultima volta che ci ho provato
> anni fa non mi e' riuscita l'impresa.
>
> Suggerimenti?
>
> --
>
>
> Respect your privacy and that of others, don't give your data to big
> corporations.
> Use alternatives like Signal (https://whispersystems.org/) for your
> messaging or
> Diaspora* (https://joindiaspora.com/) for your social networking.
>
>

-- 
Giancarlo Martini
(Replace 'AAA' con '@')
mailto:giancarlo.firAAAgmail.com 


Re: bullseye: impossibile eseguire GUI con altri utenti (xhost e ssh -X)

2020-10-04 Per discussione Davide Prina

On 04/10/20 10:21, andrea biancalana wrote:

il giorno Sun, 4 Oct 2020 10:06:44 +0200  Davide Prina ha scritto:



3)
ssh -X -oForwardX11Trusted=no -l $UTENTE 127.0.0.1



a me questo sopra funziona;



Uso testing con xfce.


ho fatto un po' di "termina sessione" e avviata una nuova sessione con 
diversi Desktop Environment.


Posso confermare che funziona tutto con xfce, ma funziona anche con 
Gnome direttamente su X.org.


Il "problema" è generato quindi da wayland.
Probabilmente non è un bug.

Quindi questo problema dovrebbe esserci per chi usa Gnome/KDE con wayland.

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook



Re: bullseye: impossibile eseguire GUI con altri utenti (xhost e ssh -X)

2020-10-04 Per discussione Davide Prina

On 04/10/20 10:21, andrea biancalana wrote:

il giorno Sun, 4 Oct 2020 10:06:44 +0200  Davide Prina ha scritto:



In pratica non funziona nessuno dei seguenti ($UTENTE è la login
dell'utente):

[...]


3)
ssh -X -oForwardX11Trusted=no -l $UTENTE 127.0.0.1


per questo mi ero dimenticato di dire che bisogna configurare 
correttamente /etc/ssh/sshd_config



a me questo sopra funziona;

e funziona come al solito anche:
ssh -X utente@localhost

anche con un utente diverso da quello che lancia il comando.

Uso testing con xfce.


grazie per il test :-)

infatti sospettavo che il problema fosse GNOME poiché ieri gli unici 
aggiornamenti erano di alcuni pacchetti di gnome (gnome-session, 
gnome-shell, ...), più poche altre cose che non avevano nulla a che fare 
con X.


Una cosa che ho notato è che ora se faccio
$ set | grep DISPLAY
DISPLAY=:0
GNOME_SETUP_DISPLAY=:1
WAYLAND_DISPLAY=wayland-0

e non so se gli ultimi due sono stati aggiunti da oggi o c'erano anche 
prima.
Vedendo questo ho pensato che potrebbe essere anche wayland che blocca, 
infatti esso offre maggiore protezione tra applicazioni GUI e magari con 
gli ultimi aggiornamenti di Gnome hanno attivato qualcosa in più...


Cercando su internet non riesco a trovare nulla... però è davvero strano 
perché questo problema dovrebbe esserci in Sid/Gnome da qualche giorno.
Se invece è una nuova funzionalità di protezione doveva segnalarmi 
questa retrocompatibilità gramite apt-listchanges che ho installato.


Fra un attimo provo a far partire il mio utente principale con un altro 
Desktop Environment.


Per ora ho trovato come workaround l'uso di "connetti come altro utente" 
che ti permette di avere due utenti collegati e entrambi poter eseguire 
applicazioni GUI... al costo di avere due DE attivi.


Se eseguo il comando sopra con un altro utente, usando il workaround, 
ottengo:

$ set | grep DISPLAY
DISPLAY=:2
GNOME_SETUP_DISPLAY=:3
WAYLAND_DISPLAY=wayland-0

invece con su - o ssh gli altri due non sono impostati e anche se li 
imposto manualmente non funziona lo stesso.


Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook



Re: bullseye: impossibile eseguire GUI con altri utenti (xhost e ssh -X)

2020-10-04 Per discussione andrea biancalana
il giorno Sun, 4 Oct 2020 10:06:44 +0200  Davide Prina  
ha scritto:


> In pratica non funziona nessuno dei seguenti ($UTENTE è la login 
> dell'utente):
[...]
> 
> 3)
> ssh -X -oForwardX11Trusted=no -l $UTENTE 127.0.0.1
> 

a me questo sopra funziona; 

e funziona come al solito anche:
ssh -X utente@localhost 

anche con un utente diverso da quello che lancia il comando.

Uso testing con xfce.



bullseye: impossibile eseguire GUI con altri utenti (xhost e ssh -X)

2020-10-04 Per discussione Davide Prina
Da oggi, quindi con qualche aggiornamento arrivato ieri non riesco più 
ad eseguire applicativi con GUI da utenti diversi da quello con cui ho 
fatto il login in gnome.


In pratica non funziona nessuno dei seguenti ($UTENTE è la login 
dell'utente):


1)
xhost +si:localuser:$UTENTE
su - $UTENTE

2)
xhost +
su - $UTENTE

3)
ssh -X -oForwardX11Trusted=no -l $UTENTE 127.0.0.1


Se cerco di eseguire qualcosa ho il seguente errore:
Unable to init server: Impossibile connettersi: Connessione rifiutata
Error: cannot open display: :0

fino a ieri funzionava.

Cercando nei log non ho trovato nulla che mi sembri utile a capire il 
problema.
Cercando in internet ho trovato problemi di molti anni fa e solo uno 
molto recente, ma senza risposte


Qualcuno che usa Bullseye aggiornata mi può confermare il non funzionamento?
Se poi qualcuno sa anche come risolvere gli sarei grato

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Motivi per non comprare/usare ms-windows7:
http://windows7sins.org/
Non autorizzo la memorizzazione del mio indirizzo su outlook