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
nco.tar.gz
Description: application/gzip
