On Thursday 30 July 2015 20.28:53 Angelos Tzotsos wrote:

Hi all,

Since there is no Geo specific mailing list, I decided to bring some issues to the factory list:

1. GRASS 7 has been released some time now. We are still maintaining 2 versions in Geo repository: grass (6.4.x) and grass7 (7.x). I think we need to merge grass7 into grass package. The question is: should we create a grass6 package for 6.x users? I am sure those users exist out there... No special thoughts. just having a consistent qgis build :-)

2. PostGIS 2 is out for quite a long time. We have postgis and postgis2 packages in our repository. postgis is disabled and all binaries are wiped out for some time now (since we removed RedHat based repositories). Question: should we merge postgis2 to postgis? and drop postgis2 package?

I know that Darin want to review it and have it in server:database:postgresql to be able to have it supporting the multi pg version we have there. His project was located here https://build.opensuse.org/project/show/home:deadpoint:postgresql I'm in favor of migrating postgis there and make it multi pg version like all other module we have.

3. openSUSE 42 has been added to the Geo project. There are some dependencies missing, but things look good in general. Should we add the needed packages in Geo repository or submit the needed packages to 42?

If we need some and they are ready on other devel-project for 42 we can use an aggregatepac no?

4. QGIS 2 is out for at least 2 years. There is no point to keep qgis and qgis2 packages anymore. Otto has proposed to have qgis package (latest stable release - 2.10.1), qgis-master (nightly build from git, as we already have) and qgis-ltr (Long Time Supported Release - 2.8.3). I agree to drop QGIS 1.x package.

I'm in favor of.

5. Several Geo packages are now in Factory so we should be very careful with what is enabled to build in Geo repository. Those packages should be used from the upstream openSUSE release (eg. geos, hdf5, proj). I made some adjustments to fix this issue.

Nice.

6. GDAL made it to Factory but was never released as part of a stable openSUSE release (it would be released in 13.3, so we need to submit it to 42). Also GDAL 2.0 was released some days ago. I am sure that most downstream projects are not ready for the switch. Should we create a gdal2 package or just wait a few months?

I've tried to package it but the perl part is totally unready doesn't respect vendor etc ... There's already number of patches to get python compiling etc. I'm pretty sure, with working with upstream we would have to wait 2.0.1 even if waiting more time to have curve geom supported is a pain Now about the lifetime announced for Leap, I'm not sure how much time upstream want to maintain 1x branch of gdal. We're just at a cross-road. My try is here https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Applic... If anybody outside would like to help (even advise).

Best, Angelos

-- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Jul 30, 2015 at 7:28 PM, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:

Hi all,

Since there is no Geo specific mailing list, I decided to bring some issues to the factory list:

<snip>

5. Several Geo packages are now in Factory so we should be very careful with what is enabled to build in Geo repository. Those packages should be used from the upstream openSUSE release (eg. geos, hdf5, proj). I made some adjustments to fix this issue.

10. There are packages where the package name doesn't match the spec file name and/or rpm name. These include libhdf4 -> hdf, ZYGrib -> zyGrib, etc. I have submitted fixes for most of these I think but I might have missed some. For hdf, I have moved the package to the OBS science project under the name "hdf", and linked the current libhdf4 package in Applications:Geo to that. This package is also currently almost accepted into openSUSE:Factory. However, I am worried about outright deleting the libhdf4 package and replacing it with an "hdf" package because a bunch of other packages depend on it (which makes sense because for many years it was the only semi-official source for the package). 11. There are also some major changes to the scientific packages, including some new dependencies. Most of these dependencies are already in Applications:Geo, but the netcdf package should soon depend on parallel-netcdf, which is not yet. 12. python-elementtree is just broken, and is built-in to python for a while now. python-yaml is properly named python-PyYAML, and is available in openSUSE:Factory. qwt is developed at KDE:Distro:Factory and should probably be linked there. qt-mobility is developed at KDE:Qt and should probably be linked there. txt2tags is developed at Education and should probably be linked there. Most astronomy tools are in Education so xephem should probably live there. 13. I think it would also be a good idea to think about which packages are not strictly related to Earth-related stuff. Here are some packages that are not directly related to earth or space science and would probably be better living in the science project: GMT, GMT4, sfcgal, and libspatialindex. Similarly, python-htmltmpl should probably live in devel:languages:python, being a python package with no directly relation to geo or astro tasks. webkit-image and zbar are not geo or astro-related but I don't know their proper place. 14. I have already requested the libnova package's devel project be switched to science (currently it is KDE:Distro:Factory). If it is accepted the Applications:Geo package should probably be linked there or to openSUSE:Factory directly. The netcdf package's devel package has already been switched to science, so that link should be changed as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org