[Gfoss] Crash di Python console in QGIS

Local Chapters GFOSS.it
1

Ciao a tutti,
volevo provare a imparare a usare la console di Python in QGIS, ma appena inizio a scrivere qualunque comando (ad es. help(iface)) QGIS crasha completamente.
Questo è quanto vedo scritto nella shell da cui ho lanciato il comdando qgis:

Warning: loading of qt translation failed [/usr/share/qt4/translations/qt_en_US]
Warning: void DBusMenuExporterPrivate::addAction(QAction*, int): Already tracking action "Toolbox" under id 295
QGIS died on signal 11Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No thread selected
No stack.
gdb returned 0
Aborted (core dumped)

Ho controllato in /proc/sys/kernel/yama/ptrace_scope e vedo scritto solamente il numero "1".
E in /etc/sysctl.d/10-ptrace.conf l'unica riga non commentata è "kernel.yama.ptrace_scope = 1"
Sono su Ubuntu 13.10, QGIS 2.2 installato da ubuntugis unstable.
Qualche idea?
grazie

Ale

--
Alessandro Sarretta

e-mail: alessandro.sarretta@gmail.com
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID: http://orcid.org/0000-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

2

On Sat, Mar 22, 2014 at 07:58:37AM +0100, Alessandro Sarretta wrote:

Ciao a tutti,
volevo provare a imparare a usare la console di Python in QGIS, ma
appena inizio a scrivere qualunque comando (ad es. help(iface)) QGIS
crasha completamente.
Questo è quanto vedo scritto nella shell da cui ho lanciato il
comdando qgis:

Warning: loading of qt translation failed
[/usr/share/qt4/translations/qt_en_US]
Warning: void DBusMenuExporterPrivate::addAction(QAction*, int):
Already tracking action "Toolbox" under id 295
QGIS died on signal 11Could not attach to process. If your uid
matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf

Il tracking dubito che funzioni senza debugging symbols agganciati alla
catena delle dipendenze. Avevo già ventilato la necessità di mantenere
dei -dbg packages per qgis, senza i quali si brancola abbastanza nel
buio quando capitano crash agli utenti con i pacchetti binari.
Comunque appurerei che effettivamente i binari che stai usando siano
allineati con i tool sottostanti, in altre parole: 'apt-get source qgis &&
apt-get build-dep qgis' e vai di dpkg-buildpackage nella source dir
relativa. Così puoi verificare se il rebuild funziona.

--
Francesco P. Lovergine

3

On Sat, Mar 22, 2014 at 11:24:04AM +0100, Francesco P. Lovergine wrote:

Il tracking dubito che funzioni senza debugging symbols agganciati alla
catena delle dipendenze. Avevo già ventilato la necessità di mantenere
dei -dbg packages per qgis, senza i quali si brancola abbastanza nel
buio quando capitano crash agli utenti con i pacchetti binari.
Comunque appurerei che effettivamente i binari che stai usando siano
allineati con i tool sottostanti, in altre parole: 'apt-get source qgis &&
apt-get build-dep qgis' e vai di dpkg-buildpackage nella source dir
relativa. Così puoi verificare se il rebuild funziona.

Ti posso confermare che con la 2.2 appena caricata in sid, la console
funziona regolarmente. Quindi ti suggerisco di seguire il mio precedente
suggerimento...

--
Francesco P. Lovergine

4

Grazie Francesco e scusa l'ignoranza, ma cosa mi stai suggerendo di fare? :slight_smile:
Tanto per capirci qualcosa....
Ho provato a lanciare

apt-get source qgis &&
apt-get build-dep qgis

e quando ho visto che mi stava chiedendo di scaricare qgis 1.7.4

Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'qgis' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/git/pkg-grass/qgis.git
Need to get 30.1 MB of source archives.
Get:1 http://us.archive.ubuntu.com/ubuntu/ saucy/universe qgis 1.7.4+1.7.5~20120320-1.1ubuntu1 (dsc) [3,095 B]
Get:2 http://us.archive.ubuntu.com/ubuntu/ saucy/universe qgis 1.7.4+1.7.5~20120320-1.1ubuntu1 (tar) [30.1 MB]

mi sono fermato...
Qualche altro indizio?
grazie mille

Ale

On 03/22/2014 11:24 AM, Francesco P. Lovergine wrote:

On Sat, Mar 22, 2014 at 07:58:37AM +0100, Alessandro Sarretta wrote:
Il tracking dubito che funzioni senza debugging symbols agganciati alla
catena delle dipendenze. Avevo già ventilato la necessità di mantenere
dei -dbg packages per qgis, senza i quali si brancola abbastanza nel
buio quando capitano crash agli utenti con i pacchetti binari.
Comunque appurerei che effettivamente i binari che stai usando siano
allineati con i tool sottostanti, in altre parole: 'apt-get source qgis &&
apt-get build-dep qgis' e vai di dpkg-buildpackage nella source dir
relativa. Così puoi verificare se il rebuild funziona.

--
Alessandro Sarretta

e-mail: alessandro.sarretta@gmail.com
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID: http://orcid.org/0000-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

5

On Sun, Mar 23, 2014 at 12:21:34AM +0100, Alessandro Sarretta wrote:

Grazie Francesco e scusa l'ignoranza, ma cosa mi stai suggerendo di fare?
:slight_smile:
Tanto per capirci qualcosa....
Ho provato a lanciare

apt-get source qgis &&
apt-get build-dep qgis

e quando ho visto che mi stava chiedendo di scaricare qgis 1.7.4

Devi aggiungere il source repository relativo alla versione che devi buildare
che evidentemente non hai inserito nel tuo sources.list.

--
Francesco P. Lovergine

6

Ok, sono arrivato alla fine della procedura suggerita da Francesco, ma il crash continua a ripetersi.
Può c'entrare qualcosa il seguente messaggio che appare al lancio di qgis da shell?

Warning: loading of qt translation failed [/usr/share/qt4/translations/qt_en_US]
Warning: void DBusMenuExporterPrivate::addAction(QAction*, int): Already tracking action "Toolbox" under id 295

grazie
Ale

On 03/23/2014 03:05 PM, Francesco P. Lovergine wrote:

On Sun, Mar 23, 2014 at 12:21:34AM +0100, Alessandro Sarretta wrote:

Grazie Francesco e scusa l'ignoranza, ma cosa mi stai suggerendo di fare?
:slight_smile:
Tanto per capirci qualcosa....
Ho provato a lanciare

apt-get source qgis &&
apt-get build-dep qgis

e quando ho visto che mi stava chiedendo di scaricare qgis 1.7.4

Devi aggiungere il source repository relativo alla versione che devi buildare
che evidentemente non hai inserito nel tuo sources.list.

--
Alessandro Sarretta

e-mail: alessandro.sarretta@gmail.com
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID: http://orcid.org/0000-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

7

On Mon, Mar 24, 2014 at 11:26:03AM +0100, Alessandro Sarretta wrote:

Ok, sono arrivato alla fine della procedura suggerita da Francesco, ma il
crash continua a ripetersi.
Può c'entrare qualcosa il seguente messaggio che appare al lancio di qgis da
shell?

Warning: loading of qt translation failed
[/usr/share/qt4/translations/qt_en_US]
Warning: void DBusMenuExporterPrivate::addAction(QAction*, int): Already
tracking action "Toolbox" under id 295

È colpa tua che insisti a usare 'sta roba dalle distribuzioni. Inizia a
compilarti a mano la roba, puoi iniziare da libc e gcc e a seguire,
se hai bisogno di una mano Sandro Furieri saprà ben darti una mano,
un mese o due e ci sei...

ROTFL

Scherzi a parte, non ho idea del motivo di una cosa del genere. Ti suggerisco
di installarti una macchina virtuale con la tua distribuzione e qgis
in forma minimale e vedere se non ti si incarta. Potrebbe benissimo essere
che a forza di tirare giù package improbabili e dalle fonti più diverse
hai reso il tutto discretamente instabile.

Sarà mica per quello che qualche deficiente continua a perdere tempo a fare
'ste robe inutili col nome stable/testing/unstable? Mah!

RI-ROTFL

Sandro ti voglio bene lo stesso, pure se non mi apprezzi :smiley:

--
Francesco P. Lovergine

8

On Mon, 24 Mar 2014 12:38:45 +0100, Francesco P. Lovergine wrote:

Sarà mica per quello che qualche deficiente continua a perdere tempo a fare
'ste robe inutili col nome stable/testing/unstable? Mah!

RI-ROTFL

Sandro ti voglio bene lo stesso, pure se non mi apprezzi :smiley:

Frankie,

sai benissimo che la stima e' assolutamente reciproca.
mai detto di non apprezzare gli sforzi dei packagers; p.es. se
spatialite si e' irrobustitita e' stato soprattutto grazie agli
sforzi ed ai suggerimenti spesso preziosi dei packagers di Debian,
Fedora e Suse (si, compresi quelli dei rompiscatole come te,
che pero' rompono sempre a ragion veduta e con ottimi argomenti
tecnicamnete piu' che ben fondati, e quindi in ultima analisi
decisamente utili e positivi).

restano comunque due punti oggettivamente critici e per nulla
risolti (almeno per quanto riguarda il mondo SQLite), sui quali
i Linux packagers possono fare evidentemente poco o nulla a
dispetto di tutti i loro sforzi:

1) sistemi WinOZ, Mac, Android, iOS e chi piu' ne ha piu' ne
    metta: dove spesso trovi pacchettizzazioni paranoiche.
    dire "colpa loro che sbagliano a scegliersi la piattaforma"
    ha sicuramente un suo valore teoretico, non e' sempre la
    soluzione pratica piu' adeguata.

2) language connectors & friends (Java, .NET/Mono, Python,
    persino LISP): dove si scatena a dismisura la fantasia piu'
    perversa, e dove ciascuno cerca di recintarsi il proprio
    orticello personale erigendosi staccionate e barriere alla
    disperata ricerca di una qualche interoperatibilita' cross
    platform.
    anche qua: limitarsi ad ignorarli spesso non basta, tanto
    se anche li cacci dalla porta ti rientrano comunque dalla
    finestra.

last but not least: mi spieghi cortesemente cosa ci trovi
di sbagliato nell'approccio Fedora di buttare quasi
immediatamente in distribuzione l'ultimissima versione
di SQLite non appena esce ?
giusto per spiegare meglio: FC20 e' uscita inizialmente
a meta' dicembre distribuendo sqlite 3.8.2; poi hanno
regolarmente seguito tutti i rilasci successivi, e dalla
settimana scorsa distribuiscono l'ultimissima 3.8.4.1
rilasciata l'11 marzo u.s.
sono tutte 3.8.x, aggiornare non implica nessunissimo
rischio, neppure vagamente potenziale: e porta sicuramente
svariati benefici (se non altro, rimuove bug ben noti).

i rischi di incoraggiare implementazioni stravaganti ed
eterodosse "do it yourself" crescono proporzionalmente
alla stagionatura dei system packages che offri, non ti
pare anche a te ?

quando i system packages sono notoriamente obsoleti e
pieni di bug mentre altrettanto notoriamente esistono
versioni successive che invece funzionano perfettamente
bene, quali altre soluzioni mi sapresti suggerire a parte
farti una sana build custom partendo dai sources ? :smiley:

ciao Sandro

9

Ciao Francesco :slight_smile:

On 03/24/2014 12:38 PM, Francesco P. Lovergine wrote:

È colpa tua che insisti a usare 'sta roba dalle distribuzioni. Inizia a
compilarti a mano la roba, puoi iniziare da libc e gcc e a seguire,
se hai bisogno di una mano Sandro Furieri saprà ben darti una mano,
un mese o due e ci sei...

mmm facciamo che passo al secondo consiglio...

ROTFL

Scherzi a parte, non ho idea del motivo di una cosa del genere. Ti suggerisco
di installarti una macchina virtuale con la tua distribuzione e qgis
in forma minimale e vedere se non ti si incarta. Potrebbe benissimo essere
che a forza di tirare giù package improbabili e dalle fonti più diverse
hai reso il tutto discretamente instabile.

Mi sono installato OSGeoLive7.9 e lì funziona.
Per ora mi accontento :slight_smile:
grazie

Ale

--
Alessandro Sarretta

e-mail: alessandro.sarretta@gmail.com
skype: alesarrett
Web: http://ilsarrett.wordpress.com
Twitter: https://twitter.com/alesarrett
Google scholar: http://scholar.google.it/citations?hl=it&user=IsyXargAAAAJ
ORCID: http://orcid.org/0000-0002-1475-8686
ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/

10

On Mon, Mar 24, 2014 at 01:27:17PM +0100, a.furieri@lqt.it wrote:

last but not least: mi spieghi cortesemente cosa ci trovi
di sbagliato nell'approccio Fedora di buttare quasi
immediatamente in distribuzione l'ultimissima versione
di SQLite non appena esce ?
giusto per spiegare meglio: FC20 e' uscita inizialmente
a meta' dicembre distribuendo sqlite 3.8.2; poi hanno
regolarmente seguito tutti i rilasci successivi, e dalla
settimana scorsa distribuiscono l'ultimissima 3.8.4.1
rilasciata l'11 marzo u.s.
sono tutte 3.8.x, aggiornare non implica nessunissimo
rischio, neppure vagamente potenziale: e porta sicuramente
svariati benefici (se non altro, rimuove bug ben noti).

Quasi nulla, tranne per il fatto che *in generale* non si ha
mai la certezza che non venga fuori qualche balzano errore
per quisquilie che nessuno nota o vengono trascurate
perché considerate innocue. E poi si tramutano in una croce
su certe architetture o sotto certe condizioni. Anche
in Debian alcuni software vengono sostituiti sic et simpliciter
perché non c'è altro sistema. È capitato e capita normalmente
con Firefox^WIceweasel, con Mysql ed un pò di altri software.
È ben noto che altri distributori preferiscono un approccio
meno conservativo. Per esempio i ragazzi di Percona aggiornano
spesso per stable il db, col risultato che di tanto in tanto
succede un patatrac :wink:
Poi sai benissimo che non esistono software senza rischio:
cambi solo bug, sostituendo alcuni esistenti con altri nuovi.
Se ti va bene i nuovi bug non li triggeri, se ti va male
sei nella pupù, magari peggio di prima...

i rischi di incoraggiare implementazioni stravaganti ed
eterodosse "do it yourself" crescono proporzionalmente
alla stagionatura dei system packages che offri, non ti
pare anche a te ?

quando i system packages sono notoriamente obsoleti e
pieni di bug mentre altrettanto notoriamente esistono
versioni successive che invece funzionano perfettamente
bene, quali altre soluzioni mi sapresti suggerire a parte
farti una sana build custom partendo dai sources ? :smiley:

Segnalare la necessità ed usare - incoraggiando - l'uso di cosette
come i backports per stable ad esempio. Che permettono
di installare roba tipicamente di testing - per es. spatialite 4.1.1
o anche sqlite3 fiammante - all'interno di stable, con un acconcio
rebuild. Il vantaggio è consentire a tutti gli utenti - compresi
quelli che di buildare non ne vogliono sapere/non possono/non sono
in grado - di godere dell'uso di una libreria o una toolchain
aggiornata.

Oppure, visto il contesto, usare testing invece di stable.
Che - mi spiace dirtelo - è stabile quanto la versione stabile
di Fedora :wink:

--
Francesco P. Lovergine

11

Il 24/03/2014 13:56, Francesco P. Lovergine ha scritto:

Oppure, visto il contesto, usare testing invece di stable.
Che - mi spiace dirtelo - è stabile quanto la versione stabile
di Fedora :wink:

Infatti: la cosa che funziona di meno in Debian testing e' il nome; ho
trovato parecchia gente che non lo installava perche' riteneva non fosse
usabile.
Personalmente uso da anni sid (unstable) senza problemi sostanziali.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

12

On Mon, Mar 24, 2014 at 01:27:17PM +0100, a.furieri@lqt.it wrote:

1) sistemi WinOZ, Mac, Android, iOS e chi piu' ne ha piu' ne
   metta: dove spesso trovi pacchettizzazioni paranoiche.
   dire "colpa loro che sbagliano a scegliersi la piattaforma"
   ha sicuramente un suo valore teoretico, non e' sempre la
   soluzione pratica piu' adeguata.

E qua c'è poco da dire... Chi è cagion del proprio male pianga se stesso.

2) language connectors & friends (Java, .NET/Mono, Python,
   persino LISP): dove si scatena a dismisura la fantasia piu'
   perversa, e dove ciascuno cerca di recintarsi il proprio
   orticello personale erigendosi staccionate e barriere alla
   disperata ricerca di una qualche interoperatibilita' cross
   platform.
   anche qua: limitarsi ad ignorarli spesso non basta, tanto
   se anche li cacci dalla porta ti rientrano comunque dalla
   finestra.

Ci sono linguaggi che sembrano fatti a posta per complicare
l'esistenza di chi li usa, ma devo dire che quelli che li
usano ci mettono spesso tanto di loro, eh! Più il linguaggio
è apparentemente accessibile e più sono le capre che lo usano.
Con risultati prevedibili. Io ho una teoria: i programmatori
dovrebbero partire a programmare dall'assembly per un periodo
significativo e solo in seguito spostarsi su
linguaggi più espressivi, e molto progressivamente.
Solo così si renderebbero veramente conto di quali danni
possono fare programmando in leggerezza.

Maledetti pythonisti/javari/phporci/rubycondi, ecc...

--
Francesco P. Lovergine

13

... i programmatori dovrebbero partire a programmare dall'assembly ...

Maledetti pythonisti/javari/phporci/rubycondi, ecc...

scusate ma non resisto:

http://it.wikipedia.org/wiki/Vero_programmatore

Ciao,

Stefano