Buongiorno a tutti,
ho bisogno di installare 2 addon di Grass, in particolare r.seg e r.evapo.PM (contenuto in HydroFOSS). Premetto che ho la possibilità di usare sia una macchina con Ubuntu 10.04 sia una con Win XP.
Siccome non mi intendo di programmazione, ho fatto delle prove con g.extension su una macchina Ubuntu 10.04 con installati Grass 6.4 e grass-dev (6.4) dai repository. Dando il comando
g.extension extension=r.seg
l’installazione non va a buon fine e mi da gli errori che riporto in allegato.
Con r.evapo.PM dando il comando
g.extension extension=HydroFOSS/r.evapo.PM
succede la stessa cosa.
Qualcuno saprebbe dirmi come potrei risolvere? Devo installare qualche componente mancante? C’è una maniera più semplice per installarli?
Cercando in rete ho trovato che potrebbe essere anche un problema del file /usr/lib/grass64/include/Make/Platform.make, idee?
Grazie a tutti.
Saluti.
Francesca Bader.
errore_r_seg.txt (8.6 KB)
errore_r_evapo_PM.txt (2.2 KB)
On Wed, Dec 08, 2010 at 04:34:07PM +0100, Francesca Bader wrote:
Qualcuno saprebbe dirmi come potrei risolvere? Devo installare qualche
componente mancante? C'è una maniera più semplice per installarli?
Cercando in rete ho trovato che potrebbe essere anche un problema del file
/usr/lib/grass64/include/Make/Platform.make, idee?
Anche forzando lo script a trovare gli header file nel posto giusto,
non andrai molto oltre. Il problema di fondo e' che il sistema di build
di grass non e' pensato per compilazioni indipendenti degli add-on.
Per avere il tutto effettivamente funzionante dovresti caricare
nel building tree principale quello che ti serve e installare
sotto una singola directory (es. /usr/local/grass), mantenendo
parimenti disponibile il tree originale di compilazione.
A quel punto g.extension funzionerebbe senza 'manovre' strane.
In pratica sarebbero da correggere gli script di compilazione
installati sul sistema (grass-dev su debian/ubuntu) per trovare i file
dove vengono effettivamente installati e non dove vengono compilati.
Alcuni tool poi non vengono installati, perche' sono disponibili
solo nel tree di build.
C'e' un ticket aperto su questo sul BTS di Debian, ma fixarlo e' piuttosto
scocciante.
--
Francesco P. Lovergine
ma guarda un po’ che roba …
http://forums.oracle.com/forums/thread.jspa?messageID=9203876
quando ho letto questo post non credevo ai miei occhi:
che ci fa SpatiaLite su un sito ufficiale di Oracle ?
un pizzico di ricerche, ed ecco spiegato il mistero:
http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html
Oracle ha preso “di peso” SQLite, ci ha aggiunto qualche API
extra, e lo ha ribattezzato BerkeleyDB
Viene definito “open source” (bontà loro), ma in effetti è
dual license:
- gratuito per applicazioni open source
- a pagamento se viene usato per apps ‘closed source’
tutto legale e limpido al 100%, per carità: SQLite è rilasciato
sotto Public Domain
(decisione forse non troppo volpina, ma tant’è … se questa
è la volonta del suo sviluppatore Richard Hipp …)
Morale: lunga vita a Richard Stallman ed alla GNU Foundation
che hanno inventato la GPL/LGPL 
ciao Sandro
p.s.: mi pare un bel caso tipico di scuola, che
spiega al volo perchè bisognerebbe evitare come
la peste tutte le “licenze mosce”, a cominciare
dalla PD, ovviamente …
In data mercoledì 8 dicembre 2010 21:52:12, a.furieri@lqt.it ha scritto:
: > ma guarda un po' che roba ...
http://forums.oracle.com/forums/thread.jspa?messageID=9203876
quando ho letto questo post non credevo ai miei occhi:
che ci fa SpatiaLite su un sito ufficiale di Oracle ?
un pizzico di ricerche, ed ecco spiegato il mistero:
http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html
Oracle ha preso "di peso" SQLite, ci ha aggiunto qualche API
extra, e lo ha ribattezzato BerkeleyDB
Viene definito "open source" (bontà loro), ma in effetti è
dual license:
- gratuito per applicazioni open source
- a pagamento se viene usato per apps 'closed source'
tutto legale e limpido al 100%, per carità: SQLite è rilasciato
sotto Public Domain
(decisione forse non troppo volpina, ma tant'è ... se questa
è la volonta del suo sviluppatore Richard Hipp ...)
Morale: lunga vita a Richard Stallman ed alla GNU Foundation
che hanno inventato la GPL/LGPL
ciao Sandro
p.s.: mi pare un bel caso tipico di scuola, che
spiega al volo perchè bisognerebbe evitare come
la peste tutte le "licenze mosce", a cominciare
dalla PD, ovviamente ....
D'accordo al 100% su PD, ma sei sicuro sul DB ?
Berkley DB mi sembra di averlo sentito già parecchi anni fa:
http://it.wikipedia.org/wiki/Berkeley_DB
Sembra che la licenza sia approvata OSI e FSF, sul fatto che sia open source
non c'è dubbio (e la gratuità non c'entra un fico).
Ciao
--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502
On Wed, Dec 08, 2010 at 11:04:01PM +0100, Alessandro Pasotti wrote:
D'accordo al 100% su PD, ma sei sicuro sul DB ?
Berkley DB mi sembra di averlo sentito già parecchi anni fa:
http://it.wikipedia.org/wiki/Berkeley_DB
Sì ma non è mai stato SQL capable: la API nativa non ha mai avuto a che vedere
con SQL. In effetti dalla 11gR2, ingloba Sqlite come ulteriore engine e
così ha aggiunto 'gratis' questa feature.
Sembra che la licenza sia approvata OSI e FSF, sul fatto che sia open source
non c'è dubbio (e la gratuità non c'entra un fico).
In realta' la licenza è praticamente una BSD con una clausola copyleft.
Ecco perche' hanno aggiunto una licenza per prodotti proprietari.
--
Francesco P. Lovergine