[GRASS-user] Re: ppa for grass 7 Ubuntu Quantal

GRASS GRASS user
1

Rashad M wrote:

I can help you with building packages for GRASS. I am already
pushing grass70 packages in ubuntugis-testing. So I am ok with
packaging.
Please tell me what to do? Is there anything special about
grass PPA?

the first thing that should happen is that the control files
should be updated to pull from the latest from the DebianGIS
git repository. All the packaging work is pretty much done and
problems solved already, no point in reinventing the wheel/chase
the same target.. (I'm not sure where UbuntuGIS is at in this
regard, if you are pulling from them. They should sync too.)

Instructions are in the src:debian/README.debian file in the
GRASS source code and http://wiki.debian.org/DebianGis

These will generally work fine in a concurrent version of
Ubuntu (or derivatives), with only minor changes to the control
file for the occasional renamed libraries.

The whole (re)package building exercise should be possible with
a simple 2-10 line script.

regards,
Hamish

2

Hello all,
nice that this discussion becomes lively now!

the first thing that should happen is that the control files
should be updated to pull from the latest from the DebianGIS
git repository.

I respect and recognise the work done there.

2 points where this is not always possible:
* your repo is at grass (6.4.2-3), we are talking about 6.4.3.x & 7.0.x
* sometimes, there are changes in upstream (in the day to day coding)
that do not correspond anymore with the package snapshot taken a a
certain point. Thus, you need to disable some patches. If not, you would
need to create new patches on nearly daily basis.

All the packaging work is pretty much done and
problems solved already, no point in reinventing the wheel/chase
the same target.. (I'm not sure where UbuntuGIS is at in this
regard, if you are pulling from them. They should sync too.)

The best would be to have 2 upstream repos in git:

* debian files for 6.3.x
* debian files for 7.0.x

LP would then pull these automatically and merge with upstream GRASS
source and build the package.
This would be really great.

Instructions are in the src:debian/README.debian file in the

does not exist in
git://git.debian.org/git/pkg-grass/grass/debian

These will generally work fine in a concurrent version of
Ubuntu (or derivatives), with only minor changes to the control
file for the occasional renamed libraries.

See suggestion above.

The whole (re)package building exercise should be possible with
a simple 2-10 line script.

What for a script are you referring to?
What woudl be the purpose?

Best regards,
Timmie

3

Hamish wrote:

> the first thing that should happen is that the control files
> should be updated to pull from the latest from the DebianGIS
> git repository.

Tim:

2 points where this is not always possible:
* your repo is at grass (6.4.2-3), we are talking about
6.4.3.x & 7.0.x

just copy in the debian/ dir from there and locally add a new
entry for the new version number at the top of the changelog
file (`dch -v` from the main source dir)

* sometimes, there are changes in upstream (in the day to
day coding) that do not correspond anymore with the package
snapshot taken a a certain point. Thus, you need to disable
some patches. If not, you would need to create new patches on
nearly daily basis.

you are right, the patches may be a problem here, but the patches
are not so many that you'd have to change them very often, maybe
once every six months. And there is a semi-automatic way to
update them. (make sure the devscripts package is installed;
there's a semi-automatic way to do everything in debian
packaging.., or maybe 4 semi-automatic ways to do everying... :slight_smile:
you might try #debian-mentors on the OFTC irc network for
for definitive advice on the latest trends there.

Probably between 6.4 and 7svn the patches will need refreshing
for sure, or disable some of them. For grass7 packages you need
to make sure that the /usr/bin/grass symlink gets dropped, so
grass 6 and 7 can be installed on the same system without
conflicts. (packaged file names must be unique distro-wide)

The best would be to have 2 upstream repos in git:

* debian files for 6.3.x
* debian files for 7.0.x

We (Frankie, me, DebianGIS,..) talked about that before, the
result of that discussion was that Debian git repo should be
for current official packaging efforts, not a sandbox for future
development. So no experimental branch there for 7 until 7 is
released and the formal packaging effort begins. But of course
it's not a big deal in git where things are, you can host that
at the ppa as you like. But if people want a grass7 binary
buildbot it'll need some gardening from time to time.

LP would then pull these automatically and merge with
upstream GRASS source and build the package.
This would be really great.

Right, the 6.4 series can do that already, it's what I'm
suggesting.

I do not know if it is possible to just checkout one subdirectory
from git. So far I haven't been able to do it. (we don't need
to re-download the entire grass 6.4 source each time from
DebianGIS)

> Instructions are in the src:debian/README.debian file
> in the

does not exist in
git://git.debian.org/git/pkg-grass/grass/debian

..the rest of my quote read:

> ... in the src:debian/README.debian file in the
> GRASS source code

see
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/debian/README.debian

> The whole (re)package building exercise should be
> possible with a simple 2-10 line script.

What for a script are you referring to?

one that is yet to be written :slight_smile: just something to download the
latest rules, apply whatever changes are needed with 'sed -i'
&/or whatever, then run debuild or whatever the ppa buildbot
needs to do.

What woudl be the purpose?

to save you lots of wasted effort and time, avoid divergence,
and avoid human error.

best,
Hamish

4

Hi,

I had updated the deian files to be in sync with DebianGIS repo and made necessary changes for grass70

···

On Tue, Apr 23, 2013 at 5:59 AM, Hamish <hamish_b@yahoo.com> wrote:

Hamish wrote:

the first thing that should happen is that the control files
should be updated to pull from the latest from the DebianGIS
git repository.

Tim:

2 points where this is not always possible:

  • your repo is at grass (6.4.2-3), we are talking about
    6.4.3.x & 7.0.x

just copy in the debian/ dir from there and locally add a new
entry for the new version number at the top of the changelog
file (dch -v from the main source dir)

  • sometimes, there are changes in upstream (in the day to
    day coding) that do not correspond anymore with the package
    snapshot taken a a certain point. Thus, you need to disable
    some patches. If not, you would need to create new patches on
    nearly daily basis.

you are right, the patches may be a problem here, but the patches
are not so many that you’d have to change them very often, maybe
once every six months. And there is a semi-automatic way to
update them. (make sure the devscripts package is installed;
there’s a semi-automatic way to do everything in debian
packaging…, or maybe 4 semi-automatic ways to do everying… :slight_smile:
you might try #debian-mentors on the OFTC irc network for
for definitive advice on the latest trends there.

Probably between 6.4 and 7svn the patches will need refreshing
for sure, or disable some of them. For grass7 packages you need
to make sure that the /usr/bin/grass symlink gets dropped, so
grass 6 and 7 can be installed on the same system without
conflicts. (packaged file names must be unique distro-wide)

The best would be to have 2 upstream repos in git:

  • debian files for 6.3.x
  • debian files for 7.0.x

We (Frankie, me, DebianGIS,…) talked about that before, the
result of that discussion was that Debian git repo should be
for current official packaging efforts, not a sandbox for future
development. So no experimental branch there for 7 until 7 is
released and the formal packaging effort begins. But of course
it’s not a big deal in git where things are, you can host that
at the ppa as you like. But if people want a grass7 binary
buildbot it’ll need some gardening from time to time.

LP would then pull these automatically and merge with
upstream GRASS source and build the package.
This would be really great.

Right, the 6.4 series can do that already, it’s what I’m
suggesting.

I do not know if it is possible to just checkout one subdirectory
from git. So far I haven’t been able to do it. (we don’t need
to re-download the entire grass 6.4 source each time from
DebianGIS)

Instructions are in the src:debian/README.debian file
in the

does not exist in
git://git.debian.org/git/pkg-grass/grass/debian

…the rest of my quote read:

… in the src:debian/README.debian file in the
GRASS source code

see
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/debian/README.debian

The whole (re)package building exercise should be
possible with a simple 2-10 line script.

What for a script are you referring to?

one that is yet to be written :slight_smile: just something to download the
latest rules, apply whatever changes are needed with ‘sed -i’
&/or whatever, then run debuild or whatever the ppa buildbot
needs to do.

What woudl be the purpose?

to save you lots of wasted effort and time, avoid divergence,
and avoid human error.

best,
Hamish

grass-user mailing list
grass-user@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-user

–

Regards,
Rashad

5

Hi Tim,

could you please test latest build of grass70 package for quantal?

startup error seems to be gone but install extension has some issues related to g.version script

···

On Tue, Apr 23, 2013 at 7:12 AM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi,

I had updated the deian files to be in sync with DebianGIS repo and made necessary changes for grass70

–

Regards,
Rashad

On Tue, Apr 23, 2013 at 5:59 AM, Hamish <hamish_b@yahoo.com> wrote:

Hamish wrote:

the first thing that should happen is that the control files
should be updated to pull from the latest from the DebianGIS
git repository.

Tim:

2 points where this is not always possible:

  • your repo is at grass (6.4.2-3), we are talking about
    6.4.3.x & 7.0.x

just copy in the debian/ dir from there and locally add a new
entry for the new version number at the top of the changelog
file (dch -v from the main source dir)

  • sometimes, there are changes in upstream (in the day to
    day coding) that do not correspond anymore with the package
    snapshot taken a a certain point. Thus, you need to disable
    some patches. If not, you would need to create new patches on
    nearly daily basis.

you are right, the patches may be a problem here, but the patches
are not so many that you’d have to change them very often, maybe
once every six months. And there is a semi-automatic way to
update them. (make sure the devscripts package is installed;
there’s a semi-automatic way to do everything in debian
packaging…, or maybe 4 semi-automatic ways to do everying… :slight_smile:
you might try #debian-mentors on the OFTC irc network for
for definitive advice on the latest trends there.

Probably between 6.4 and 7svn the patches will need refreshing
for sure, or disable some of them. For grass7 packages you need
to make sure that the /usr/bin/grass symlink gets dropped, so
grass 6 and 7 can be installed on the same system without
conflicts. (packaged file names must be unique distro-wide)

The best would be to have 2 upstream repos in git:

  • debian files for 6.3.x
  • debian files for 7.0.x

We (Frankie, me, DebianGIS,…) talked about that before, the
result of that discussion was that Debian git repo should be
for current official packaging efforts, not a sandbox for future
development. So no experimental branch there for 7 until 7 is
released and the formal packaging effort begins. But of course
it’s not a big deal in git where things are, you can host that
at the ppa as you like. But if people want a grass7 binary
buildbot it’ll need some gardening from time to time.

LP would then pull these automatically and merge with
upstream GRASS source and build the package.
This would be really great.

Right, the 6.4 series can do that already, it’s what I’m
suggesting.

I do not know if it is possible to just checkout one subdirectory
from git. So far I haven’t been able to do it. (we don’t need
to re-download the entire grass 6.4 source each time from
DebianGIS)

Instructions are in the src:debian/README.debian file
in the

does not exist in
git://git.debian.org/git/pkg-grass/grass/debian

…the rest of my quote read:

… in the src:debian/README.debian file in the
GRASS source code

see
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/debian/README.debian

The whole (re)package building exercise should be
possible with a simple 2-10 line script.

What for a script are you referring to?

one that is yet to be written :slight_smile: just something to download the
latest rules, apply whatever changes are needed with ‘sed -i’
&/or whatever, then run debuild or whatever the ppa buildbot
needs to do.

What woudl be the purpose?

to save you lots of wasted effort and time, avoid divergence,
and avoid human error.

best,
Hamish

grass-user mailing list
grass-user@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-user

–

Regards,
Rashad

6

could you please test latest build of grass70 package for quantal?

startup error seems to be gone but install extension has some issues
related to g.version script

I get for grass70:
Hit RETURN to continue
Starting GRASS GIS...
python: can't open file '/usr/lib/grass/etc/gui/wxpython/gis_set.py':
[Errno 2] No such file or directory
Received EXIT message from GUI.
GRASS is not started. Bye.

I get for grass (6.4.x):

3D view mode: /usr/lib/grass64/lib/libgrass_ogsf.6.4.3svn.so: symbol
TIFFSetField, version GDAL_1.8 not defined in file libgdal.so.1 with
link time reference

Shall we track those error in the LP bug tracker?

Which one? UbuntuGIS or the GRASS project one?

Thanks for coming in and regards,
Timmie

7

On Wed, Apr 24, 2013 at 11:15 PM, Tim Michelsen
<timmichelsen@gmx-topmail.de> wrote:
...

I get for grass (6.4.x):

3D view mode: /usr/lib/grass64/lib/libgrass_ogsf.6.4.3svn.so: symbol
TIFFSetField, version GDAL_1.8 not defined in file libgdal.so.1 with
link time reference

Just FYI - this came up end of last year, too:

On Thu, Nov 15, 2012 at 1:39 PM, Markus Neteler wrote:

On Thu, Nov 15, 2012 at 11:47 AM, Patrick S. wrote:

Hi,

I observe two errors in my GRASS-GIS 6.4.2 from UbuntuGIS-Repository with
sqlite as database. Does someone know whether these refer to missing
dependancies of UbuntuGIS or are errors of my system and - in case of the
latter - eventually how I can fix this?

1.) When starting GRASS I get the message: "3D view mode:
/usr/lib/grass64/lib/libgrass_ogsf.6.4.2.so: symbol TIFFSetField, version
GDAL_1.8 not defined in file libgdal.so.1 with link time reference".

There seems to be some GDAL confusion in the Ubuntu built, the same
was reported on the Italian GRASS list. It was suggested to check the
dependencies:

dpkg -s grass

or
dpkg -s grass-core

Markus

8

* sometimes, there are changes in upstream (in the day to
day coding) that do not correspond anymore with the package
snapshot taken a a certain point. Thus, you need to disable
some patches. If not, you would need to create new patches on
nearly daily basis.

you are right, the patches may be a problem here, but the patches
are not so many that you'd have to change them very often, maybe
once every six months. And there is a semi-automatic way to
update them. (make sure the devscripts package is installed;
there's a semi-automatic way to do everything in debian
packaging.., or maybe 4 semi-automatic ways to do everying... :slight_smile:
you might try #debian-mentors on the OFTC irc network for
for definitive advice on the latest trends there.

Probably between 6.4 and 7svn the patches will need refreshing
for sure, or disable some of them.

That's what I usually do because the rest above is just too complicated.
at least for me.

The best would be to have 2 upstream repos in git:

* debian files for 6.3.x
* debian files for 7.0.x

We (Frankie, me, DebianGIS,..) talked about that before, the
result of that discussion was that Debian git repo should be
for current official packaging efforts, not a sandbox for future
development. So no experimental branch there for 7 until 7 is
released and the formal packaging effort begins.

OK, sure. that's your policy and I can understand.

But of course
it's not a big deal in git where things are, you can host that
at the ppa as you like. But if people want a grass7 binary
buildbot it'll need some gardening from time to time.

right. the more we are the higher the probability that we can keep it
running!

And this offers, as M. Neteler pointed out, more possibilities for
discovering bugs.

I do not know if it is possible to just checkout one subdirectory
from git. So far I haven't been able to do it. (we don't need

Me neither. maybe someone else can help?

Instructions are in the src:debian/README.debian file
in the

does not exist in
git://git.debian.org/git/pkg-grass/grass/debian

..the rest of my quote read:

... in the src:debian/README.debian file in the
GRASS source code

see
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/debian/README.debian

The whole (re)package building exercise should be
possible with a simple 2-10 line script.

What for a script are you referring to?

one that is yet to be written :slight_smile: just something to download the
latest rules, apply whatever changes are needed with 'sed -i'
&/or whatever, then run debuild or whatever the ppa buildbot
needs to do.

That's the thing called recipe. LP does it already!

Otherwise, set up & bzr dailydeb & pbuilder.
Fairly easy.

Thanks for your attention.
Happy to see that things start moving.
If you attend one of these FOSS4G meetups, please advertise the GRASS
packaging.

How do you think about the addons?

shall we have a grass-addons package?

Best,
Timmie

9

Am 24.04.2013 23:21, schrieb Markus Neteler:

On Wed, Apr 24, 2013 at 11:15 PM, Tim Michelsen
<timmichelsen@gmx-topmail.de> wrote:
...

I get for grass (6.4.x):

3D view mode: /usr/lib/grass64/lib/libgrass_ogsf.6.4.3svn.so: symbol
TIFFSetField, version GDAL_1.8 not defined in file libgdal.so.1 with
link time reference

Just FYI - this came up end of last year, too:

On Thu, Nov 15, 2012 at 1:39 PM, Markus Neteler wrote:

On Thu, Nov 15, 2012 at 11:47 AM, Patrick S. wrote:

Hi,

I observe two errors in my GRASS-GIS 6.4.2 from UbuntuGIS-Repository with
sqlite as database. Does someone know whether these refer to missing
dependancies of UbuntuGIS or are errors of my system and - in case of the
latter - eventually how I can fix this?

1.) When starting GRASS I get the message: "3D view mode:
/usr/lib/grass64/lib/libgrass_ogsf.6.4.2.so: symbol TIFFSetField, version
GDAL_1.8 not defined in file libgdal.so.1 with link time reference".

There seems to be some GDAL confusion in the Ubuntu built, the same
was reported on the Italian GRASS list. It was suggested to check the
dependencies:

dpkg -s grass

or
dpkg -s grass-core

Here's the message from Italian list:
http://www.mail-archive.com/grass-italia@listserv.unipr.it/msg03143.html

So the reason:
the PPA builds NVIZ against 1.9.0-3 from Ubuntu.
if you have also UbuntuGIS PPA activated, you get 1.9.2-2 installed.
So either you would need to downgrade in Synaptic to 1.9.0-3

But I assume that everyone using the PPA would also like the UbuntuGIS
packages.

So I added the UbuntuGIS & UbuntuGIS unstable as dependencies to the
GRASS stable ppa.
As a result, you would need to enable UbuntuGIS unstable on your machine.

Please be aware that in this case, we depend on UbuntuGIS to update gdal
package after release of Ubuntu 13.04.

Please report any further errors to:
https://answers.launchpad.net/grass
https://bugs.launchpad.net/grass

10

Tim,

your grass7.0 also gives error in g.version right?. I think it might be a bug in grass which need to be fixed.

regarding addon packaging. We can create packages like
grassaddons(full addons)
grassaddons-imgagery
grassaddons-vector
grassaddons-raster
grasssaddons-general

I can give it a try if everyone agrees on package naming and is necessary

···

On Thu, Apr 25, 2013 at 3:51 AM, Tim Michelsen <timmichelsen@gmx-topmail.de> wrote:

Am 24.04.2013 23:21, schrieb Markus Neteler:

On Wed, Apr 24, 2013 at 11:15 PM, Tim Michelsen
<timmichelsen@gmx-topmail.de> wrote:
…

I get for grass (6.4.x):

3D view mode: /usr/lib/grass64/lib/libgrass_ogsf.6.4.3svn.so: symbol
TIFFSetField, version GDAL_1.8 not defined in file libgdal.so.1 with
link time reference

Just FYI - this came up end of last year, too:

On Thu, Nov 15, 2012 at 1:39 PM, Markus Neteler wrote:

On Thu, Nov 15, 2012 at 11:47 AM, Patrick S. wrote:

Hi,

I observe two errors in my GRASS-GIS 6.4.2 from UbuntuGIS-Repository with
sqlite as database. Does someone know whether these refer to missing
dependancies of UbuntuGIS or are errors of my system and - in case of the
latter - eventually how I can fix this?

1.) When starting GRASS I get the message: “3D view mode:
/usr/lib/grass64/lib/libgrass_ogsf.6.4.2.so: symbol TIFFSetField, version
GDAL_1.8 not defined in file libgdal.so.1 with link time reference”.

There seems to be some GDAL confusion in the Ubuntu built, the same
was reported on the Italian GRASS list. It was suggested to check the
dependencies:

dpkg -s grass

or
dpkg -s grass-core

Here’s the message from Italian list:
http://www.mail-archive.com/grass-italia@listserv.unipr.it/msg03143.html

So the reason:
the PPA builds NVIZ against 1.9.0-3 from Ubuntu.
if you have also UbuntuGIS PPA activated, you get 1.9.2-2 installed.
So either you would need to downgrade in Synaptic to 1.9.0-3

But I assume that everyone using the PPA would also like the UbuntuGIS
packages.

So I added the UbuntuGIS & UbuntuGIS unstable as dependencies to the
GRASS stable ppa.
As a result, you would need to enable UbuntuGIS unstable on your machine.

Please be aware that in this case, we depend on UbuntuGIS to update gdal
package after release of Ubuntu 13.04.

Please report any further errors to:
https://answers.launchpad.net/grass
https://bugs.launchpad.net/grass

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

–

Regards,
Rashad

11

your grass7.0 also gives error in g.version right?. I think it might be
a bug in grass which need to be fixed.

No, just this one:
python: can't open file '/usr/lib/grass/etc/gui/wxpython/gis_set.py':
[Errno 2] No such file or directory
Received EXIT message from GUI.

12

Dear community of GRASS users,
is there a need for having packages for the GRASS addons?

Please give feedback by:
(+1 / 0 / -1)

And of saying yes (+1), would you voluteer in heping with packaing and
maintaining the daily builds of the PPA?

Please give feedback by:
(+1 / 0 / -1)

Below a suggestion for the packaging structure:
regarding addon packaging. We can create packages like
grassaddons(full addons)
grassaddons-imgagery
grassaddons-vector
grassaddons-raster
grasssaddons-general

I can give it a try if everyone agrees on package naming and is necessary

I started off on with creating the general infrastructure:
https://code.launchpad.net/grass-addons

* just wait for the import to finish
* start off with the debian files as usual.
* then run the recipe:
https://code.launchpad.net/~grass/+recipe/grass-addons-daily

Regards,
Timmie

13

Tim Michelsen <timmichelsen@gmx-topmail.de> writes:

+1

unfortunately not able to help.

Dear community of GRASS users,
is there a need for having packages for the GRASS addons?

Please give feedback by:
(+1 / 0 / -1)

And of saying yes (+1), would you voluteer in heping with packaing and
maintaining the daily builds of the PPA?

Please give feedback by:
(+1 / 0 / -1)

Below a suggestion for the packaging structure:
regarding addon packaging. We can create packages like
grassaddons(full addons)
grassaddons-imgagery
grassaddons-vector
grassaddons-raster
grasssaddons-general

I can give it a try if everyone agrees on package naming and is necessary

I started off on with creating the general infrastructure:
https://code.launchpad.net/grass-addons

* just wait for the import to finish
* start off with the debian files as usual.
* then run the recipe:
https://code.launchpad.net/~grass/+recipe/grass-addons-daily

Regards,
Timmie

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

<#secure method=pgpmime mode=sign>

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44

Fax (D): +49 - (0)3 21 21 25 22 44

email: Rainer@krugs.de

Skype: RMkrug

14

Tim wrote:

Below a suggestion for the packaging structure:
regarding addon packaging. We can create packages like
grassaddons(full addons)
grassaddons-imgagery
grassaddons-vector
grassaddons-raster
grasssaddons-general

if you do it, please name the pacakges like "grass-addons-*",
and install to /usr/lib/grass64/addons/. We'd have to patch our
lib/init/init.sh in the main ubuntu package to add that dir
to the GRASS_ADDON_PATH if it existed on the system.

I'd base the decision on if to package them all together or
in groups based on how big the resulting package was. if it's
just a couple of MB, keep it simple in one pkg-- note for
official debian packaging all the docs and help page images
would need to be split out into another platform-inspecific
-data &/or -docs package(s). So your 4-5 packages above grow
to 12-15 of them.. for a weekly ppa build it doesn't matter
though. (the reason for that on Debian is to avoid duplicated
space in the archives since 11 different hardware platforms,
each needing their own binary pkg but can share the -data one)

note some of the things in addons are either experiments or
still in development, AFAIK by placing the module in the
../Makefile the developer is announcing that it is fit for
human consumption.

thanks,
Hamish

15

Someone wrote:

> your grass7.0 also gives error in g.version right?. I think
> it might be a bug in grass which need to be fixed.

Tim wrote:

No, just this one:
python: can't open file
'/usr/lib/grass/etc/gui/wxpython/gis_set.py':
[Errno 2] No such file or directory
Received EXIT message from GUI.

that should be /usr/lib/grass70/etc/ not /grass/?
Did the version number extract part of the build "rules" script
work? maybe it collapsed to an empty string.

Hamish

16

No, just this one:
python: can't open file
'/usr/lib/grass/etc/gui/wxpython/gis_set.py':
[Errno 2] No such file or directory
Received EXIT message from GUI.

that should be /usr/lib/grass70/etc/ not /grass/?
Did the version number extract part of the build "rules" script
work? maybe it collapsed to an empty string.

OK, we shall review that.
No time today.

Reported here:
https://bugs.launchpad.net/grass/+bug/1173387

LP bug tracker now enabled for all packages of GRASS PPA

See also:
http://grasswiki.osgeo.org/wiki/Ubuntu_Packaging#Report_bugs_and_issues

17

Below a suggestion for the packaging structure:
regarding addon packaging. We can create packages like
grassaddons(full addons)
grassaddons-imgagery
grassaddons-vector
grassaddons-raster
grasssaddons-general

I question when looking at :
http://trac.osgeo.org/grass/browser/grass-addons

I wonder:
* why is there a separate branch per major grass version?
* what is the policy for backwards / upwards compatibility?
* shall we instead of grouping by command type group by version?

if you do it, please name the pacakges like "grass-addons-*",
and install to /usr/lib/grass64/addons/. We'd have to patch our
lib/init/init.sh in the main ubuntu package to add that dir
to the GRASS_ADDON_PATH if it existed on the system.

Why do we not make this default, then?

I'd base the decision on if to package them all together or
in groups based on how big the resulting package was. if it's
just a couple of MB, keep it simple in one pkg-- note for
official debian packaging all the docs and help page images
would need to be split out into another platform-inspecific
-data &/or -docs package(s). So your 4-5 packages above grow
to 12-15 of them.. for a weekly ppa build it doesn't matter
though. (the reason for that on Debian is to avoid duplicated
space in the archives since 11 different hardware platforms,
each needing their own binary pkg but can share the -data one)

Let's get the thing going on experimental basis and then see how we
could organise it.

18

Tim wrote:

I question when looking at :
http://trac.osgeo.org/grass/browser/grass-addons

I wonder:
* why is there a separate branch per major grass version?

between grass 5, 6, and 7 the library APIs change and the
module options/flags change, so a module written for one
often won't work on another without some slight modification.

* what is the policy for backwards / upwards compatibility?

within major version backwards compatibility. A module written
for 6.0.0 will still work with any future 6.y.z versions.

It is likely for compiled modules the ABI is not stable, and
you will have to recompile for the current version. Any python
and shell scripts should be forward-compatible though. If you
try to run a compiled addon module against a different libgis
than the one it was built for, you will get the "please untangle
versions" error. "g.version -r" shows the libgis rev for this
reason:

g.version -r: Print the GIS library revision number and time

GRASS 6.4.1 (2011)
Revision: 43636
Date: 2010-09-22 22:18:42 +0200 (Wed, 22 Sep 2010)

GRASS 6.4.2 (2012)
Revision: 45934
Date: 2011-04-13 13:19:03 +0200 (Wed, 13 Apr 2011)

GRASS 6.4.3svn (2013)
Revision: 50937
Date: 2012-02-26 02:14:51 +1300 (Sun, 26 Feb 2012)

GRASS 6.5.svn (2013)
Revision: 50936
Date: 2012-02-26 02:14:47 +1300 (Sun, 26 Feb 2012)

it doesn't change very much, but often enough to mean that
you need to recompile your addons when switching between minor
versions. (e.g. it's been more than a year since it changed
last)

* shall we instead of grouping by command type group by
version?

an addon package containing grass7 addons should exclusively
depend on the grass7-core package etc. so at minimum it must
be grouped by major version.

Hamish:

> and install to /usr/lib/grass64/addons/. We'd have to
> patch our lib/init/init.sh in the main ubuntu package
> to add that dir to the GRASS_ADDON_PATH if it existed
> on the system.

Tim:

Why do we not make this default, then?

because Debian installs grass in a funny place (/usr/lib/grassXY),
any system packages need to be available to all users equally-
so in a common OS dir, and personal addons can't go into a
system dir where the user does not have write access.
It's not a big deal to do the patch.

regards,
Hamish

19

Tim wrote:

Reported here:
https://bugs.launchpad.net/grass/+bug/1173387

LP bug tracker now enabled for all packages of GRASS PPA

See also:
http://grasswiki.osgeo.org/wiki/Ubuntu_Packaging#Report_bugs_and_issues

is that a ppa specific bug tracker, or the main ubuntu one?
I wouldn't pollute the main one with our ppa experiments, but
keep it clean for problems in the official packages.
?

(not really sure how the whole ppa integration works)

thanks,
Hamish