From: "Marco van Hulten" Subject: Re: [new] geo/nco To: "Stuart Henderson" Cc: "Landry Breuil" , , "Martin Reindl" Date: Sun, 07 Dec 2025 17:14:17 +0100 On Sat Dec 6, 2025 at 4:34 PM CET, Stuart Henderson wrote: > On 2025/12/06 14:31, Marco van Hulten wrote: >> On Sat Dec 6, 2025 at 8:33 AM CET, Landry Breuil wrote: >> > Le Fri, Dec 05, 2025 at 09:57:54PM +0100, Marco van Hulten a écrit : >> >> On Fri Dec 5, 2025 at 6:41 PM CET, Landry Breuil wrote: >> >> > Le Fri, Dec 05, 2025 at 05:42:35PM +0100, Marco van Hulten a écrit : >> >> >> With NCO you can manipulate and analyse netCDF and similar files. It is >> >> >> a useful addition to to tools that are already there. >> >> >> >> >> >> So you could do this: >> >> >> >> >> >> wget https://cluster.klima.uni-bremen.de/~fmaussion/teaching/climate/CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc >> >> >> ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head >> >> >> ncrename -d month,mo CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc >> >> >> ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head >> >> >> >> >> >> to rename the time axis. >> >> >> >> >> >> Apropos, geo/cdo has some of the same functionality, but it is designed >> >> >> to handle data variables, not meta information like axes names, so >> >> >> geoscientists will quickly be looking for something like NCO. >> >> >> >> >> >> OK to add this? >> >> > >> >> > from a first look, you'll need at least fixing the proper versionning >> >> > for the @so that should be @lib with the version, and a BDEP on >> >> > print/texinfo. >> >> > >> >> > @so lib/libnco-5.3.6.so -> that doesnt use the 0.0 from SHARED_LIBS. >> >> >> >> I added print/texinfo (and see that this is needed). I see that this is >> >> in pkg/PLIST. There are no @lib entries. Does that mean I do not need >> >> to include SHARED_LIBS? >> > >> > well, it depends on what is the usecase for libnco. If it's a library >> > that's dlopened by binaries (eg generally what's called 'plugin') then >> > it can be a .so without versioning, but if it's a library things link >> > against (eg consumers of an api provided by the library) then the build >> > system should be adapted so that it is properly versionned with the >> > version coming from SHARED_LIBS, and available i nthe build env as a >> > variable (eg ${LIBnco_VERSION} iirc) >> >> I don't think there is any software besides NCO that links to libnco, so >> what I sent yesterday at 09:57:54PM +0100 without the SHARED_LIBS should >> be right. > > ...new tar attached addressing most of my comments below; > > also > > warning: library filename /usr/obj/ports/nco-5.3.6/build-amd64/src/nco/.libs/libnco-5.3.6.so has no version number > > and > > -rw-r--r-- 1 _pbuild _pbuild 1649976 Dec 6 14:53 libnco-5.3.6.so > -rw-r--r-- 1 _pbuild _pbuild 2824108 Dec 6 14:53 libnco.a > -rw-r--r-- 1 _pbuild _pbuild 1293 Dec 6 14:53 libnco.la > lrwxr-xr-x 1 _pbuild _pbuild 15 Dec 6 14:53 libnco.so -> libnco-5.3.6.so > > that symlink shouldn't be there > > : COMMENT = NCO manipulates and analyses data stored in netCDF format > > generally don't repeat the name of the software here, you already know > the port/package name when you see that information. > > how about this instead? > > CLI tools to manipulate and analyse netCDF/HDF/DAP data Yes, that is fine. > : V = 5.3.6 > : DISTNAME = nco-$V > : > : DIST_TUPLE += github nco nco $V . > > no benefit to the extra vars here; that can be written as > > DIST_TUPLE += github nco nco 5.3.6 . > > : BUILD_DEPENDS = print/texinfo > : LIB_DEPENDS = archivers/libaec \ > : devel/gsl \ > : math/netcdf \ > : math/hdf5 \ > : math/udunits \ > : textproc/libxml \ > : devel/gettext > > deps go lower in the Makefile (near the CONFIGURE lines is common) > > : # Newer version of GNU texinfo than the one in base (4.8) is needed > > the comment is pretty much implied by using ports texinfo > > : MAKEINFO = "${LOCALBASE}/bin/gmakeinfo" > > that isn't passed through to the build, so it's doing nothing > > also prefer not to patch the generated configure script directly; unless > it's very difficult to do so it's better to patch the input files and > regen configure etc. Yes, this is nicer. I removed patch-configure and things still work fine as we autogen now. > - upstreams description used in pkg/DESCR seems rather blurb-y > and doesn't make much sense, I borrowed the rather better description > from https://nco.sourceforge.net/#Definition instead That is much better description indeed! > not covered by my updated tar - any idea what this is about or whether > it's important? (I checked and it's not due to setting SEPARATE_BUILD) > > /usr/obj/ports/nco-5.3.6/build-amd64/src/nco/ncks -O -7 --cnk_dmn time,10 in.nc in_4c.nc > gmake[2]: /usr/obj/ports/nco-5.3.6/build-amd64/src/nco/ncks: No such file or directory There are more of such stderr messages during build about files not existing (both scripts and data files), but they do exist when I look. I'll report these and the rest I see in stderr upstream. ncks(1) works fine when running it from the command line, both script /home/_ports/pobj/nco-5.3.6/build-amd64/src/nco/ncks and the installed binary /usr/local/bin/ncks. I think it is fine to commit. In the tarball attached the only change is the removal of patch/patch-configure w.r.t. your last tarball. Marco