Re: netcdf packages
On Mon, Mar 31, 2014 at 01:41:09PM +0200, Nico Schlömer wrote: Everything that is interesting in the current netcdf-bin is included in the C-library of netCDF. The only binaries included in the C++ and Fortran builds are configuration assistants that are losing their significance in the new CMake builds anyways. Hence, I'd say it's reasonable to make netcdfc-bin the new netcdf-bin. So a Conflicts: netcdf-bin Provides: netcdf-bin might do the trick, right? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140403070203.gb12...@an3as.eu
Re: netcdf packages
Everything that is interesting in the current netcdf-bin is included in the C-library of netCDF. The only binaries included in the C++ and Fortran builds are configuration assistants that are losing their significance in the new CMake builds anyways. Hence, I'd say it's reasonable to make netcdfc-bin the new netcdf-bin. Cheers, Nico On Sat, Mar 29, 2014 at 8:37 AM, Eric L. ewl+debian+nospam2...@lavar.de wrote: Hi, On 28 March 2014 09:20:01 CET, Dominique Dumont d...@debian.org wrote: On Thursday 27 March 2014 22:21:55 Nico Schlömer wrote: The question is: how to avoid breaking the above package when upgrading netcdf to netcdf-c, netcdf-fortran, netcdf-cxx ? What about declaring netcdf-bin as dummy package depending on the 3 new ones, and ask (or file bugs against) the dependent package(r)s to change their dependencies. Eric I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no need to CC me on these lists. Thanks! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/27a60a5d-44f9-41c2-b45e-52be470bf...@email.android.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK6Z60fCu0eBoQz7Oqmy4RY=q6nnue6re4d605bikupdo8u...@mail.gmail.com
Re: netcdf packages
Hi, On 28 March 2014 09:20:01 CET, Dominique Dumont d...@debian.org wrote: On Thursday 27 March 2014 22:21:55 Nico Schlömer wrote: The question is: how to avoid breaking the above package when upgrading netcdf to netcdf-c, netcdf-fortran, netcdf-cxx ? What about declaring netcdf-bin as dummy package depending on the 3 new ones, and ask (or file bugs against) the dependent package(r)s to change their dependencies. Eric I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no need to CC me on these lists. Thanks! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/27a60a5d-44f9-41c2-b45e-52be470bf...@email.android.com
Re: netcdf packages
On Thursday 27 March 2014 22:21:55 Nico Schlömer wrote: The question remains on how we can move this forward in a sensible way. One possibility is to split the existing netcdf package into three separate ones netcdf-c, netcdf-fortran, netcdf-cxx, to reflect the upstream structure. What is your opinion on this? Matching upstream structure makes sense. But you will have to consider the impact on the packages that depend on netcdf-bin: $ apt-cache rdepends netcdf-bin netcdf-bin Reverse Depends: netcdf-bin:i386 v-sim-plugins libnetcdf-dev minc-tools science-nanoscale-physics science-meteorology-dev science-dataacquisition gis-workstation gis-remotesensing The question is: how to avoid breaking the above package when upgrading netcdf to netcdf-c, netcdf-fortran, netcdf-cxx ? Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2572115.ZjIftkGxgs@ylum
Re: netcdf packages
On Friday 15 December 2006 16:40, Kevin B. McCarty wrote: While I think of it, please add cfortran as a Build-Depends, and in debian/rules do something to ensure that the build happens using the copy of cfortran.h in Debian, to ensure consistency. Probably the easiest way would be just to cp -pf /usr/include/cfortran.h $(CURDIR)/fortran/ in the configure target to overwrite the existing copy. In debian/rules clean target, do the following: rm -f $(CURDIR)/fortran/cfortran.h in order to avoid bloating the diff.gz. From netcdf upstream: upstream Jeff Whitaker [EMAIL PROTECTED] writes: Warren Turkal wrote: The cfortran.h file is in /usr/include on Debian systems after installing the cfortran package. Does netcdf use a cfortran.h in /usr/include instead of the one within the tarball when it is available? If not, could you please change netcdf to do so for beta5? wt Warren: Why? What if it is broken, or out of date? I'd rather netcdf use it's own cfortran.h, which it knows it can trust. -Jeff NetCDF includes it's own cfortran.h, which will be used in its build. Any cfortran.h on the system will not be used, it will be ignored by netCDF. The netCDF fortran API looks for, and uses, its own cfortran.h, not depending on it to be installed, or using it if it is. This is necessary: some modifications to netCDF's cfortran.h allow it to be built on even more platforms than the original cfortran.h allows. Thanks, Ed /upstream Considering these replies, should I even bother hacking in the cfortran.h from the Debian package? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Warren Turkal wrote: On Friday 15 December 2006 17:22, Warren Turkal wrote: Known issues: * haven't bumped soname for C++ yet. I want to see if upstream will do that. Ed from upstream had a question: *** I'm not too strong yet on how these numbers are used, but last time I looked into it the conclusion was to release version 3.6.2 of netCDF with: -version-info 0:0:0 Any comments would be welcome. Do you think this is correct? *** I'm not clear exactly how libtool translates -version-info flags to version numbers. (If I read the libtool script right, then -version-info X:Y:Z translates to libfoo.so.(X-Z).Z.Y on Linux.) However, it is definitely the case that having -version-info 0:0:0 will create a library with filename libwhatever.so.0.0.0 and soname libwhatever.so.0. This will break any binary compatibility with previous netcdf versions, so it would definitely become necessary to rebuild existing programs against the new netcdf. (This is always a risk when a Debian packager hacks in shared library support, and then later upstream decides to support building shared libraries in the official source.) If upstream is sketchy about library versioning, please ask them to read the Library interface versions chapter of the libtool Info docs, and hopefully all will become clear :-) Maybe also point them at the C++ ABI FAQ mentioned in a previous email of mine: http://www.trolltech.com/developer/knowledgebase/362/ Can you please comment on this issue as to what would help us ship a non-modified upstream soname? If upstream were to ship netcdf 3.6.2 using -version-info 4:0:0, that would put their soversion higher than any that had previously been hacked in by downstream suppliers. So you might ask them if they could do that. (Again this would necessitate rebuild of netcdf-depending programs. But my best guess is that ABI compatibility from netcdf version 3.6.1 has already been broken, based on your description of the situations in which kst-plugins had a segfault. At least having upstream start with libnetcdf.so.4 would guarantee a monotonic progression of soversions in the Debian package history.) Of course, it's up to them whether they are willing to do so. If they don't, Debian will have to support whatever their official decision is. * researching cfortran.h issue I have asked upstream to prefer the system version of cfortran.h over the one included in the tarball. I saw your copy of their response, which was basically we always want to prefer our own version in case the system version is old and buggy. As far as I can tell, though, netcdf changes to cfortran.h 4.3 are pretty minimal, and consist mainly of adding cygwin, Pathscale, and gfortran support. The gfortran support has been patched into Debian's cfortran.h independently, and of course Pathscale compiler and cygwin support are not relevant to the build on Debian. As cfortran maintainer I'd prefer to see you force use of the system cfortran.h during the build, but if you don't want to go against upstream in this way I understand. It is really a pity that the cfortran author is no longer active in maintaining it; forks like this are kind of getting out of control. This comment from upstream, quoted in your other email, I'd like to understand better: NetCDF includes it's own cfortran.h, which will be used in its build. Any cfortran.h on the system will not be used, it will be ignored by netCDF. The netCDF fortran API looks for, and uses, its own cfortran.h, not depending on it to be installed, or using it if it is. Does this mean that the libnetcdf-dev package will ship its own copy of cfortran.h somewhere (maybe at /usr/include/netcdf/cfortran.h or something similar)? How does a Fortran compilation using libnetcdff ensure that the compiler picks up that file (which it should do to be consistent) and not /usr/include/cfortran.h ? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Friday 15 December 2006 17:22, Warren Turkal wrote: Known issues: * haven't bumped soname for C++ yet. I want to see if upstream will do that. Ed from upstream had a question: *** I'm not too strong yet on how these numbers are used, but last time I looked into it the conclusion was to release version 3.6.2 of netCDF with: -version-info 0:0:0 Any comments would be welcome. Do you think this is correct? *** Can you please comment on this issue as to what would help us ship a non-modified upstream soname? * researching cfortran.h issue I have asked upstream to prefer the system version of cfortran.h over the one included in the tarball. * info pages not moved yet, as I am working with upstream on a configure script issue The next beta release will use a newer version of autotools that addresses this problem entirely. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Warren Turkal wrote:
On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
This is weird: if you install your new packages of netcdf, the existing
kst-plugins package (from Sid) on your system should automatically pick
up the new libnetcdf_c++.so.3 library and function properly, fixing the
crash. ÂI can only think of two reasons why this would not work:
This could have something to do with the largefile support.
The --enable-64bits enables support for netcdf files over 2GB. This probably
changes some functions to return 64 bit instead of 32 bit numbers. Is the
appropriate solution to bump the soname in this case?
At first I thought that might be a possibility. But in looking through
the configure.ac script, it seems that on Linux, --enable-64bits doesn't
actually do anything! Check out lines 570 - 621 of configure.ac, there
is no case for Linux. Also, netcdf-install.txt says this option has no
effect on Linux.
Maybe you are thinking of --disable-largefile, which omits OS support
for large files (i.e. files larger than 2 GB). But large files are
enabled by default as far as I can tell.
*) the soname of libnetcdf_c++.so has changed since the version in Sid
(in which case the binary package name must be changed and indeed kst
must then be rebuilt against the new library),
I think this is what you are referring to.
Was: libnetcdf.so.3.6.1
Now: libnetcdf.so.3.6.2
Not that...
You may also be referring to the links to those files, which are
libnetcdf.so.3 in both cases.
Close. There should always exist a link with the same name as the
soname, pointing to the actual file, e.g.
libnetcdf.so.3 - libnetcdf.so.3.6.2
You can find the actual soname built into the shared library file with
the following command:
objdump -x /usr/lib/libnetcdf.so.3 | grep SONAME
and it turns out to be libnetcdf.so.3 for both your .debs and the ones
already in Sid.
*) OR, the soname was not changed even though it should have been.
(This is not an uncommon situation since C++ is hard to maintain a
stable ABI in.) ÂActually, I seem to remember you saying that shared lib
support was hacked into the Debian packages, meaning you will need to
care for the soname yourself.
The sonames in the old version were an illusion. Should we diverge from
upstream on the soname?
It's generally bad to diverge sonames from upstream if at all possible.
If it's necessary, one usually adds something Debian-specific on the
end, like libnetcdf.so.3d (d for Debian; I know, it's ugly) and
renames the package to something like libnetcdf3d.
I did a diff between netcdf-3.6.1/src/cxx and netcdf-3.6.2-beta4/cxx and
found some changes in netcdfcpp.h that look possibly problematic. For
instance, in the NcFile class, the add_dim() and add_var() methods have
been made virtual. In NcTypedComponent, a virtual destructor was added;
in NcError, an inline function, a static function, and two static
variables were added. I'm not sure if these changes are sufficient to
break the ABI. Trolltech has an FAQ about maintaining C++ ABI
compatibility if you want to look through it:
http://www.trolltech.com/developer/knowledgebase/362/
Another thing I noticed is that the old .debs have a single file
libnetcdf.so.3.6.1 including both C and FORTRAN code, while your new
.debs have separated it out into two files, libnetcdf.so.3.6.2 and
libnetcdff.so.3.6.2. This is going to break anything that depended on
the FORTRAN bindings in the old package, since those bindings are no
longer in the same file. Again, I don't know whether any of the
reverse-dependencies of libnetcdf3 use FORTRAN bindings, but you may
wish to check that.
For these two reasons, I would add the d to the end of the soname and
change the name of the package (only the runtime package, not the -dev
package) in order to be safe. Then, once the new .debs are eventually
uploaded (this will require a wait for the NEW queue due to the new
binary package name), request a rebuild of all depending packages.
Possibly you should ask for comments about this on debian-devel, we are
probably getting a little beyond the scope of debian-mentors. Maybe
also send these comments/questions along upstream...
Incidentally, if you run ldd /usr/lib/libnetcdff.so.3 on the FORTRAN
bindings, it does not show libgfortran.so.1 nor libnetcdf.so.3, both of
which it uses symbols from. This should be fixed to ensure accurate
library dependencies. (In particular, you want to ensure that the
libnetcdf3 package picks up a Depends: libgfortran1 via
${shlibs:Depends}.) Similarly, libnetcdf_c++.so.3 should ideally also
have a built-in dependency on libnetcdf.so.3.
Will reply to your other email in a minute.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Re: netcdf packages
On Friday 15 December 2006 16:20, Kevin B. McCarty wrote: Another thing I noticed is that the old .debs have a single file libnetcdf.so.3.6.1 including both C and FORTRAN code, while your new .debs have separated it out into two files, libnetcdf.so.3.6.2 and libnetcdff.so.3.6.2. This is going to break anything that depended on the FORTRAN bindings in the old package, since those bindings are no longer in the same file. Again, I don't know whether any of the reverse-dependencies of libnetcdf3 use FORTRAN bindings, but you may wish to check that. I already looked into that issue. Three packages seemed to build depend on the netcdf libs and g77. Of those 3, none appeared to use netcdf apis in the fortran code in the packages. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Warren Turkal wrote:
On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
1) Why did you make the libnetcdf++3 package into a dummy package and
move the C++ bindings into the libnetcdf3 package? ÂIf the soname of the
C++ package needs to evolve faster than that of the C/FORTRAN bindings,
as I speculated above, this would be a really good reason to keep the
C++ bindings in a separate package.
The netcdf libs are shipped as one tarball.
Sorry, I meant, keep the C++ bindings in the same source package, but
why not put libnetcdf_c++.so.3.6.2 into a different binary package
(libnetcdf++3) as was done before? If you feel things are better with
all libs in one package, that's OK, I was just curious about the reason.
3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
package, not in the runtime library (libnetcdf3) package. ÂPlease do not
ship libtool *.la files at all, as has been requested many times by the
release team. ÂSee for instance the discussion at bug #400140.
This advice seems contrary to [1]. #400140 also seems to contradict [1].
Maybe
[1] needs to be updated?
Possibly... I don't know enough to get involved in that argument,
though. All I know is that people whose opinion I highly respect seem
to hate .la files ...
4) Your libnetcdf-dev package is missing a Depends line. ÂIt should
Depend at least upon the netcdf shared library package(s), upon any
*-dev packages that ship files #included by its header files, and upon
any *-dev packages that ship static libs depended upon by netcdf static
libs. Â(The last is slightly controversial, since there are people who
hate static libraries; for that you might be able to use a Recommends
instead of Depends.)
Is there a better way than just listing Depends: libnetcdf3 in the control
file for libnetcdf-dev?
Unfortunately not that I am aware of.
I don't think that it depends on more than the standard lib.
OK. At least, maybe add a Depends on libc6-dev | libc-dev, and a
Suggests or Recommends (as you think appropriate) on gfortran.
I have attached the new control file. Can you please check it out?
Source: netcdf
Section: science
Priority: optional
Maintainer: Warren Turkal [EMAIL PROTECTED]
Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, texinfo
While I think of it, please add cfortran as a Build-Depends, and in
debian/rules do something to ensure that the build happens using the
copy of cfortran.h in Debian, to ensure consistency. Probably the
easiest way would be just to
cp -pf /usr/include/cfortran.h $(CURDIR)/fortran/
in the configure target to overwrite the existing copy. In debian/rules
clean target, do the following: rm -f $(CURDIR)/fortran/cfortran.h in
order to avoid bloating the diff.gz.
[snip]
Package: libnetcdf3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: netcdf, netcdfg, libnetcdf++3
Conflicts: netcdf3 ( 3.3.1-1), netcdfg3 ( 3.6.2), libnetcdf++3 ( 3.6.2)
Replaces: netcdf3, netcdfg3
Please also have it replace libnetcdf++3 ( 3.6.2) if you are going to
have the new libnetcdf++3 be a dummy package.
[snip]
Package: libnetcdf-dev
Section: devel
Architecture: any
Depends: libnetcdf3, ${shlibs:Depends}, ${misc:Depends}
${shlibs:Depends} isn't useful for a -dev package, since static libs
(*.a files) don't contain any dependency information that dpkg-shlibdeps
can extract. As mentioned above, please also add a dependency on
libc6-dev | libc-dev and perhaps a Recommends or Suggests on gfortran.
Conflicts: netcdf-dev, netcdfg-dev ( 3.6.2)
again, please add the Replaces for these
Rest looks fine.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Friday 15 December 2006 16:40, Kevin B. McCarty wrote:
Warren Turkal wrote:
On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
1) Why did you make the libnetcdf++3 package into a dummy package and
move the C++ bindings into the libnetcdf3 package? ÂIf the soname of the
C++ package needs to evolve faster than that of the C/FORTRAN bindings,
as I speculated above, this would be a really good reason to keep the
C++ bindings in a separate package.
The netcdf libs are shipped as one tarball.
Sorry, I meant, keep the C++ bindings in the same source package, but
why not put libnetcdf_c++.so.3.6.2 into a different binary package
(libnetcdf++3) as was done before? If you feel things are better with
all libs in one package, that's OK, I was just curious about the reason.
I figured that they'd have to be recompiled for each tarball anyway, so I
didn't see a reason to split them since the lib are each only a few hundred K
as most.
3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
package, not in the runtime library (libnetcdf3) package. ÂPlease do not
ship libtool *.la files at all, as has been requested many times by the
release team. ÂSee for instance the discussion at bug #400140.
This advice seems contrary to [1]. #400140 also seems to contradict [1].
Maybe [1] needs to be updated?
Possibly... I don't know enough to get involved in that argument,
though. All I know is that people whose opinion I highly respect seem
to hate .la files ...
I removed the .la files from the next release.
4) Your libnetcdf-dev package is missing a Depends line. ÂIt should
Depend at least upon the netcdf shared library package(s), upon any
*-dev packages that ship files #included by its header files, and upon
any *-dev packages that ship static libs depended upon by netcdf static
libs. Â(The last is slightly controversial, since there are people who
hate static libraries; for that you might be able to use a Recommends
instead of Depends.)
Is there a better way than just listing Depends: libnetcdf3 in the
control file for libnetcdf-dev?
Unfortunately not that I am aware of.
I saw some shlibs file in the debian directory of the older package, and
thought maybe I was missing something.
I don't think that it depends on more than the standard lib.
OK. At least, maybe add a Depends on libc6-dev | libc-dev, and a
Suggests or Recommends (as you think appropriate) on gfortran.
I have suggested it for next release.
However, the refblas3-dev package depends on g77. Does that indicate that I
should depend on gfortran rather than suggest or recommend?
I have attached the new control file. Can you please check it out?
Source: netcdf
Section: science
Priority: optional
Maintainer: Warren Turkal [EMAIL PROTECTED]
Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, texinfo
While I think of it, please add cfortran as a Build-Depends, and in
debian/rules do something to ensure that the build happens using the
copy of cfortran.h in Debian, to ensure consistency. Probably the
easiest way would be just to
cp -pf /usr/include/cfortran.h $(CURDIR)/fortran/
in the configure target to overwrite the existing copy. In debian/rules
clean target, do the following: rm -f $(CURDIR)/fortran/cfortran.h in
order to avoid bloating the diff.gz.
I am researching this one. Would deleting the cfortran.h at the end cause the
diff.gz to be messed up in a subsequent build? Should I copy the version in
the package somewhere else and copy back at the end instead?
[snip]
Package: libnetcdf3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: netcdf, netcdfg, libnetcdf++3
Conflicts: netcdf3 ( 3.3.1-1), netcdfg3 ( 3.6.2), libnetcdf++3 (
3.6.2) Replaces: netcdf3, netcdfg3
Please also have it replace libnetcdf++3 ( 3.6.2) if you are going to
have the new libnetcdf++3 be a dummy package.
Done.
[snip]
Package: libnetcdf-dev
Section: devel
Architecture: any
Depends: libnetcdf3, ${shlibs:Depends}, ${misc:Depends}
${shlibs:Depends} isn't useful for a -dev package, since static libs
(*.a files) don't contain any dependency information that dpkg-shlibdeps
can extract.
Removed.
As mentioned above, please also add a dependency on
libc6-dev | libc-dev and perhaps a Recommends or Suggests on gfortran.
Added Depends on libc6-dev | libc-dev and Suggests for gfortran.
Conflicts: netcdf-dev, netcdfg-dev ( 3.6.2)
again, please add the Replaces for these
added
New release (pre4) at [1].
Known issues:
* haven't bumped soname for C++ yet. I want to see if upstream will do that.
* researching cfortran.h issue
* info pages not moved yet, as I am working with upstream on a configure
script issue
wt
[1]http://www.penguintechs.org/~wt/debian/netcdf/
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric
Re: netcdf packages
Hi Warren, Warren Turkal wrote: On Wednesday 13 December 2006 10:55, Warren Turkal wrote: I think that we should just go for it. W00T! OK, you've convinced me that compiling with gfortran shouldn't be a problem. (But please try to make sure that maintainers of any new packages introduced depending on the FORTRAN bindings of netcdf are aware of the issue.) KST can actually plot netcdf graphs after the upgrade in library. It just crashed on all my netcdf files before. This is another reason to upgrade the library. Unfortunately, it lookes like kst will have to be relinked with the new library to work without crashing. It uses the c++ binding. I suspect anything using that binding would need to be recompiled as well. Did the netcdf lib ever go through the C++ ABI change? I think it must have at least been built with the new g++: benjo (sid)[2]:~% apt-cache show libnetcdf++3| grep Depends Depends: [...], libstdc++6 (= 4.1.0) ^^ According to packages.qa.debian.org, the version of kst in Sid/Etch was built in November '06, long after the current version of netcdf was uploaded (in July '06). So any problems with kst's use of netcdf in Sid/Etch are not likely to be due to the C++ ABI transition. I don't quite understand the exact problem you are facing, though. If I have read your email correctly, you see the following: a) libnetcdf++3 package from Sid, kst-plugins package from Sid == Crash b) libnetcdf++3 package from your new .debs, kst-plugins package from Sid == Crash c) libnetcdf++3 package from your new .debs, kst-plugins package rebuilt against your new .debs == Works OK This is weird: if you install your new packages of netcdf, the existing kst-plugins package (from Sid) on your system should automatically pick up the new libnetcdf_c++.so.3 library and function properly, fixing the crash. I can only think of two reasons why this would not work: *) the soname of libnetcdf_c++.so has changed since the version in Sid (in which case the binary package name must be changed and indeed kst must then be rebuilt against the new library), *) OR, the soname was not changed even though it should have been. (This is not an uncommon situation since C++ is hard to maintain a stable ABI in.) Actually, I seem to remember you saying that shared lib support was hacked into the Debian packages, meaning you will need to care for the soname yourself. Here are some other comments regarding your -beta4-1~pre3 .debs, now that I've taken the time to look at them. (Note, I have only looked at the .debs, not at the source package.) 1) Why did you make the libnetcdf++3 package into a dummy package and move the C++ bindings into the libnetcdf3 package? If the soname of the C++ package needs to evolve faster than that of the C/FORTRAN bindings, as I speculated above, this would be a really good reason to keep the C++ bindings in a separate package. 2) I don't think there should be info files in libnetcdf++3 (regardless of whether it is a dummy package or a shared library package). I see you do ship the info files in libnetcdf-dev as well (where they should be), but they should be in /usr/share/info, not under /usr/share/doc/libnetcdf-dev where info won't look for them. (On second look, you already have noticed this problem.) 3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev package, not in the runtime library (libnetcdf3) package. Please do not ship libtool *.la files at all, as has been requested many times by the release team. See for instance the discussion at bug #400140. 4) Your libnetcdf-dev package is missing a Depends line. It should Depend at least upon the netcdf shared library package(s), upon any *-dev packages that ship files #included by its header files, and upon any *-dev packages that ship static libs depended upon by netcdf static libs. (The last is slightly controversial, since there are people who hate static libraries; for that you might be able to use a Recommends instead of Depends.) 5) Wherever you Conflict against an old package (such as libnetcdf-dev's Conflicts: netcdf-dev, netcdfg-dev ( 3.6.2)) because of file conflicts, you also need a Replaces line with similar contents. This is because under some circumstances, dpkg will try to unpack a new package before completely removing an old package that is conflicted against. Some of these issues could have been caught by comparing the contents of the netcdf binary packages in Sid and your new packages. I find that debdiff is a really useful tool for such comparisons, though of course YMMV. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf packages
I wanted to reply to the two parts of your mail separately, so please check out this one and the next one. On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote: think it must have at least been built with the new g++: benjo (sid)[2]:~% apt-cache show libnetcdf++3| grep Depends Depends: [...], libstdc++6 (= 4.1.0) ^^ According to packages.qa.debian.org, the version of kst in Sid/Etch was built in November '06, long after the current version of netcdf was uploaded (in July '06). So any problems with kst's use of netcdf in Sid/Etch are not likely to be due to the C++ ABI transition. I don't quite understand the exact problem you are facing, though. If I have read your email correctly, you see the following: a) libnetcdf++3 package from Sid, kst-plugins package from Sid == Crash b) libnetcdf++3 package from your new .debs, kst-plugins package from Sid == Crash c) libnetcdf++3 package from your new .debs, kst-plugins package rebuilt against your new .debs == Works OK Correct. This is weird: if you install your new packages of netcdf, the existing kst-plugins package (from Sid) on your system should automatically pick up the new libnetcdf_c++.so.3 library and function properly, fixing the crash. I can only think of two reasons why this would not work: This could have something to do with the largefile support. The --enable-64bits enables support for netcdf files over 2GB. This probably changes some functions to return 64 bit instead of 32 bit numbers. Is the appropriate solution to bump the soname in this case? The crappy thing about this situation is that you can build the library with or without the support for the large files. The good thing is the following: if you opt for --enable-64bits, you can read all files, you will only write new style files, however. If you don't --enable-64bits, you can only read and write old style files. This may be why my netcdf files crash with kst. They may be new style, and the kst plugin for netcdf may not handle the error correctly when the netcdf lib says it can't read the file, or kst could be failing when getting back an improperly sized return value. To be perfectly honest with you, netcdf support is worthless if it doesn't support the new style files. Most people are using them now. *) the soname of libnetcdf_c++.so has changed since the version in Sid (in which case the binary package name must be changed and indeed kst must then be rebuilt against the new library), I think this is what you are referring to. Was: libnetcdf.so.3.6.1 Now: libnetcdf.so.3.6.2 You may also be referring to the links to those files, which are libnetcdf.so.3 in both cases. *) OR, the soname was not changed even though it should have been. (This is not an uncommon situation since C++ is hard to maintain a stable ABI in.) Actually, I seem to remember you saying that shared lib support was hacked into the Debian packages, meaning you will need to care for the soname yourself. The sonames in the old version were an illusion. Should we diverge from upstream on the soname? wt -- Warren Turkal
Re: netcdf packages
On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
1) Why did you make the libnetcdf++3 package into a dummy package and
move the C++ bindings into the libnetcdf3 package? If the soname of the
C++ package needs to evolve faster than that of the C/FORTRAN bindings,
as I speculated above, this would be a really good reason to keep the
C++ bindings in a separate package.
The netcdf libs are shipped as one tarball.
2) I don't think there should be info files in libnetcdf++3 (regardless
of whether it is a dummy package or a shared library package). I see
you do ship the info files in libnetcdf-dev as well (where they should
be), but they should be in /usr/share/info, not under
/usr/share/doc/libnetcdf-dev where info won't look for them.
(On second look, you already have noticed this problem.)
I am working with the netcdf developers on this issue actually.
3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
package, not in the runtime library (libnetcdf3) package. Please do not
ship libtool *.la files at all, as has been requested many times by the
release team. See for instance the discussion at bug #400140.
This advice seems contrary to [1]. #400140 also seems to contradict [1]. Maybe
[1] needs to be updated?
For the time being, I am not adding them to the package at all.
4) Your libnetcdf-dev package is missing a Depends line. It should
Depend at least upon the netcdf shared library package(s), upon any
*-dev packages that ship files #included by its header files, and upon
any *-dev packages that ship static libs depended upon by netcdf static
libs. (The last is slightly controversial, since there are people who
hate static libraries; for that you might be able to use a Recommends
instead of Depends.)
Is there a better way than just listing Depends: libnetcdf3 in the control
file for libnetcdf-dev?
I don't think that it depends on more than the standard lib.
5) Wherever you Conflict against an old package (such as libnetcdf-dev's
Conflicts: netcdf-dev, netcdfg-dev ( 3.6.2)) because of file
conflicts, you also need a Replaces line with similar contents. This is
because under some circumstances, dpkg will try to unpack a new package
before completely removing an old package that is conflicted against.
Some of these issues could have been caught by comparing the contents of
the netcdf binary packages in Sid and your new packages. I find that
debdiff is a really useful tool for such comparisons, though of course
YMMV.
I have attached the new control file. Can you please check it out?
wt
[1]http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries
--
Warren Turkal
Source: netcdf
Section: science
Priority: optional
Maintainer: Warren Turkal [EMAIL PROTECTED]
Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, texinfo
Standards-Version: 3.7.2
Package: libnetcdf++3
Section: libs
Architecture: any
Depends: libnetcdf3
Description: Dummy upgrade package for libnetcdf3
This is a dummy package to transition to a unified library package
for the NetCDF libraries.
.
Once installed, it may be removed.
Package: netcdfg-dev
Section: devel
Architecture: any
Depends: libnetcdf-dev
Description: Dummy upgrade package for libnetcdf-dev
This is a dummy package to transition to a new development package
for the NetCDF libraries.
.
Once installed, it may be removed.
Package: libnetcdf3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: netcdf, netcdfg, libnetcdf++3
Conflicts: netcdf3 ( 3.3.1-1), netcdfg3 ( 3.6.2), libnetcdf++3 ( 3.6.2)
Replaces: netcdf3, netcdfg3
Description: An interface for scientific data access to large binary data
NetCDF (network Common Data Form) is an interface for scientific
data access and a freely-distributed software library that provides an
implementation of the interface. The netCDF library also defines a
machine-independent format for representing scientific data.
Together, the interface, library, and format support the creation,
access, and sharing of scientific data.
Package: libnetcdf-dev
Section: devel
Architecture: any
Depends: libnetcdf3, ${shlibs:Depends}, ${misc:Depends}
Conflicts: netcdf-dev, netcdfg-dev ( 3.6.2)
Description: Development kit for NetCDF
NetCDF (network Common Data Form) is an interface for scientific
data access and a freely-distributed software library that provides an
implementation of the interface. The netCDF library also defines a
machine-independent format for representing scientific data.
Together, the interface, library, and format support the creation,
access, and sharing of scientific data.
.
This package includes everything needed for developing in C, C++,
Fortran 77, and Fortran 90.
Package: netcdf-bin
Section: science
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Programs for reading and writing NetCDF files
Contains the programs ncdump and ncgen which convert NetCDF
Re: netcdf packages
On Tuesday 12 December 2006 19:35, you wrote:
Regarding the use of gfortran -- are you aware that g77 and gfortran
produce object code with somewhat incompatible ABIs? See my previous
emails on this topic here:
Yes, I am aware. Since there is neither a fortran policy nor a good record of
best practice (different packages use gfortran or g77 randomly. That's why I
mentioned Gfortran so prominently in the changelog.
However, I feel it's also important to mention the following.
[EMAIL PROTECTED]:~/tmp$ grep-dctrl -F Build-Depends 'netcdfg-dev' -s
Package
/var/lib/apt/lists/http.us.debian.org_debian_dists_etch_main_source_Sources
netcdf_packages.txt
[EMAIL PROTECTED]:~/tmp$ grep-dctrl -F Build-Depends 'g77' -s
Package
/var/lib/apt/lists/http.us.debian.org_debian_dists_etch_main_source_Sources
g77_packages.txt
[EMAIL PROTECTED]:~/tmp$ join -j 2 netcdf_packages.txt g77_packages.txt | wc -l
3
[EMAIL PROTECTED]:~/tmp$ join -j 2 netcdf_packages.txt g77_packages.txt |
awk '{print $1}'
grace
grace6
kst
I think it is safe to say that the g77 bindings of the netcdf library are
only possibly used by those 3 packages.
KST:
[EMAIL PROTECTED]:~/src/kst/kst-1.3.1$ find . -name '*.f*' -o -name '*.F*'
./kst/tests/healpix/healpix_example_sm.fits
./configure.files
There's no fortran in kst, it seems.
Grace:
[EMAIL PROTECTED]:~/src/grace/grace-5.1.20$ find . -name '*.f*' -o -name '*.F*'
./grace_np/testf_np.f
./examples/logistic.fit
One fortran 77 file.
[EMAIL PROTECTED]:~/src/grace/grace-5.1.20$ grep -i nf_ ./grace_np/testf_np.f
NetCDF appears to not be used in Grace as all netcdf APIs begin with nf_
in the f77 binding.
Grace6:
Same story as for grace above. No NetCDF used in fortran77 files.
Unfortunately it seems that no one is yet endeavoring to make sure there
is a reasonable transition plan for libraries from g77 to gfortran.
(Possibly I will try to do something about this post-etch, if I have
time and once gfortran supports all the g77 intrinsics.) For that
reason I recommend that all FORTRAN libraries, when possible, be
compiled with g77 for the moment.
If netcdf does not have any functions returning REAL (single-precision)
or COMPLEX, maybe building netcdf with gfortran is OK though.
I don't think that this problem should hold back netcdf as the majority of
modern fortran use of netcdf requires the f90 bindings. G77 does not
include support for f90 and I feel it is a disservice to the scientific
users to not include the f90 support.
I also feel that the results of the above research indicate that there will
be no fallout with packages in the main archive with regard to compiling
the netcdf lib with gfortran.
I think that we should just go for it. W00T!
Comments?
wt
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Tuesday 12 December 2006 18:41, Warren Turkal wrote: Uploaded to [1]. Another new package release @ [1]. This is the first set that is totally lintian clean. Changes: netcdf (3.6.2-beta4-1~pre3) unstable; urgency=low . * added symlinks for libraries in /usr/lib * changed conflicts so that upgrades would go smoothly Known problems: * info pages in wrong place Also, I am also building kst against the lib as a stress test right now. wt [1]http://penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Wednesday 13 December 2006 10:55, Warren Turkal wrote: I think that we should just go for it. W00T! KST can actually plot netcdf graphs after the upgrade in library. It just crashed on all my netcdf files before. This is another reason to upgrade the library. Unfortunately, it lookes like kst will have to be relinked with the new library to work without crashing. It uses the c++ binding. I suspect anything using that binding would need to be recompiled as well. Did the netcdf lib ever go through the C++ ABI change? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
IANADD (but I feel like arguing anyway) On Mon, 11 Dec 2006 11:34:02 -0700 Warren Turkal [EMAIL PROTECTED] wrote: On Monday 11 December 2006 03:42, Patrick Schönfeld wrote: * debian/copyright: * IMO you should mention the ones who previous did packaging The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. On this I disagree with Patrick. IMHO, the copyright file is no place for history. This information is contained in the changelog already. Since you revamped the package completely, you are the only author and copyright holder for the debian directory material, that's what has to go into copyright (as well as which license you put on these files). The previous maintainers would have to be listed here only if you were still using their work. Regards, Thibaut.
Re: netcdf packages
On Monday 11 December 2006 15:53, Warren Turkal wrote: New version (3.6.2-beta4~pre1) at [1]. This version sorts before the last one so you will have to manually remove the prior packages I posted if you used apt* to install them. Here's the changelog entry. netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) * Combined all libs into one package. * Upstream version fixes inconsistent manpage (closes: #353332) * Touched up descriptions on some of the packages I just wanted to ping everyone for comments on the package @ [1]. I will cut a -1 release ready for sponsored upload if I don't hear anything else. wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Thibaut Paumard wrote: On Mon, 11 Dec 2006 11:34:02 -0700 Warren Turkal [EMAIL PROTECTED] wrote: [...] The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. On this I disagree with Patrick. IMHO, the copyright file is no place for history. This information is contained in the changelog already. Well, at last we do not disagree to each other. In general i think copyright's existence is to honor every bodies copyright and licensing. Therefore *if* the package is based on previous packages i feel like it is for history. But if not (if 99,999% of the work were done by Warren) ... see next paragraph. Since you revamped the package completely, you are the only author and copyright holder for the debian directory material, that's what has to go into copyright (as well as which license you put on these files). Yes, thats the fact i wasn't aware of when i wrote my comments. In this case i agree with you. If - and only if - Warren totally reworked everything (exceptions for the name of the package and changelog) it shouldn't be necessary (IMHO!) to list previous authors there. But it would be nicer to do so. Greets Patrick signature.asc Description: OpenPGP digital signature
Re: netcdf packages
On Tuesday 12 December 2006 10:06, schönfeld / in-medias-res.com wrote: Yes, thats the fact i wasn't aware of when i wrote my comments. In this case i agree with you. If - and only if - Warren totally reworked everything (exceptions for the name of the package and changelog) it shouldn't be necessary (IMHO!) to list previous authors there. But it would be nicer to do so. The fact is I downloaded the source and started from a dh_make to package the source. I didn't use any code from the old package because it is a pre-debhelper package. I actually have had to compile it locally for a while (for F90 support) and used that experience for developing the package. So, should the prior package author attribution be included or not? I would like to address this issue ASAP. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Warren Turkal wrote: So, should the prior package author attribution be included or not? not in copyright, no. if you upload your new packages, we can go then through them piece by piece tomorrow. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Tuesday 12 December 2006 16:22, Daniel Baumann wrote: not in copyright, no. I removed that paragraph. if you upload your new packages, we can go then through them piece by piece tomorrow. Uploaded to [1]. Some notes of things already addressed: 1) I have already deleted watch.ex post 1~pre2. 2) I have already deleted netcdf.doc-base.EX post 1~pre2. wt [1]http://penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote: netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) Hi Warren, Regarding the use of gfortran -- are you aware that g77 and gfortran produce object code with somewhat incompatible ABIs? See my previous emails on this topic here: http://lists.debian.org/debian-science/2005/09/msg00071.html http://lists.debian.org/debian-science/2006/06/msg5.html Unfortunately it seems that no one is yet endeavoring to make sure there is a reasonable transition plan for libraries from g77 to gfortran. (Possibly I will try to do something about this post-etch, if I have time and once gfortran supports all the g77 intrinsics.) For that reason I recommend that all FORTRAN libraries, when possible, be compiled with g77 for the moment. If netcdf does not have any functions returning REAL (single-precision) or COMPLEX, maybe building netcdf with gfortran is OK though. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: netcdf packages
Hi Warren, Warren Turkal wrote: I have worked tonight to produce new netcdf packages for the NetCDF libraries. They are located at [1]. I would like some feedback on them. They are based on cdbs. [2] is a link to a WNPP bug about this package. I would like to adopt the package, if possible. i can not sponsor your upload because I am not a DD, but i may provide you some hints: * Remove all files from debian/ with .ex ending. They are example files and if you don't need them, then you should not include them. If you need them, then rename and edit them and whatever it needs to do further. * debian/rules * : Remove the unneeded extra line at EOF * : I don't know much about your package but is configure parameter --enable-64bit right? You will not build for 64bit systems only in debian imho * Personally i would use 'install -d' to create directories while building and get rid of those .dirs files which do contain standard directories only * debian/*.dirs: Seee above rules comment * debian/copyright: * According to debian policy 12.5 you *must* say where the upstream sources (if any) were obtained * You should name the original authors of the package and the Debian maintainer(s) who were involved with its creation * IMO you should mention the ones who previous did packaging * The lines at the end of the file seem to be unnecessary * debian/changelog: * Should contain changelog entries of previous debian versions * Must contain a notice that you are new maintainer Further notes: It sounds a bit strange that your package has a version -beta-pre. I'm not sure if you really want to package a pre-beta (what actually is an alpha version in my sense). Also i don't like cdbs much. IMO it makes packages / packages build process unclearly. Best Regards Patrick signature.asc Description: OpenPGP digital signature
Re: netcdf packages
Hi Warren, some further notes (as an addition to my previous written notes), as i actually figured to get it built (pooh, was some work). General: In my other mail i told you that i think it is bad to use a pre-beta. Now that i got this package to compile my impression is hardened because while compiling there do occur about several hundred of warnings. Okay, but i commit, that i don't know if a stable release of netcdf is building cleaner. Also build process is taking a *very* long time, but thats because of CDBS. debian/control: * You miss some build-deps. The build process does use texi2dvi while building, which is in package texinfo. Also you need to build-depend on tex because texi2dvi does not work without a running tex installation. Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). Best Regards Patrick Warren Turkal wrote: Debian Mentors, I have worked tonight to produce new netcdf packages for the NetCDF libraries. They are located at [1]. I would like some feedback on them. They are based on cdbs. [2] is a link to a WNPP bug about this package. I would like to adopt the package, if possible. Thanks, wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ [2]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321336 signature.asc Description: OpenPGP digital signature
Re: netcdf packages
On Monday 11 December 2006 03:42, Patrick Schönfeld wrote: * Remove all files from debian/ with .ex ending. They are example files and if you don't need them, then you should not include them. If you need them, then rename and edit them and whatever it needs to do further. I was evaluating the utility of the watch.ex and doc-base.EX files before I deleted them. I am planning on removing watch.ex and possibly using the doc-base.EX to itegrate the documentation. * debian/rules * : Remove the unneeded extra line at EOF I like the empty line at the end of a file. It allow me to bring the cursor back to the left at the bottom. * : I don't know much about your package but is configure parameter --enable-64bit right? You will not build for 64bit systems only in debian imho The enable-64bit doesn't enable 64bit archs, it enables 64bit offsets in the files so that they can be over 2GB. * Personally i would use 'install -d' to create directories while building and get rid of those .dirs files which do contain standard directories only Is that somehow better than using the debhelper to do it? The directories are created so that I can load them up with files. * debian/*.dirs: Seee above rules comment * debian/copyright: * According to debian policy 12.5 you *must* say where the upstream sources (if any) were obtained Okay. I have that in my local repository for the next release. Here the text I added to the top of the copyright file. This package was put together by Warren Turkal [EMAIL PROTECTED] with sources obtained from the http://www.unidata.ucar.edu/software/netcdf/ site. * You should name the original authors of the package and the Debian maintainer(s) who were involved with its creation above * IMO you should mention the ones who previous did packaging The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. * The lines at the end of the file seem to be unnecessary removed * debian/changelog: * Should contain changelog entries of previous debian versions added in local repository for next release * Must contain a notice that you are new maintainer done locally Further notes: It sounds a bit strange that your package has a version -beta-pre. I'm not sure if you really want to package a pre-beta (what actually is an alpha version in my sense). Also i don't like cdbs much. IMO it makes packages / packages build process unclearly. NetCDF developers are incredibly conservative about releases. The last beta release was on Aug. 16. This is what is packaged. It doesn't have any API regressions that I or my scientists have been able to find. I have scientists running some pretty intense numerical simulations based on these libraries. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
On Monday 11 December 2006 05:34, schönfeld / in-medias-res.com wrote: General: In my other mail i told you that i think it is bad to use a pre-beta. Now that i got this package to compile my impression is hardened because while compiling there do occur about several hundred of warnings. Okay, but i commit, that i don't know if a stable release of netcdf is building cleaner. Also build process is taking a *very* long time, but thats because of CDBS. The latest full release of the NetCDF libs are no cleaner, unfortunately. In fact, the lastest full release dosn't support shared libs. The Debian package has hacked in support to build the shared libs. debian/control: * You miss some build-deps. The build process does use texi2dvi while building, which is in package texinfo. Also you need to build-depend on tex because texi2dvi does not work without a running tex installation. Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). I want the package to be sorted before a real -1 release in the debian archive so that folks installing the pre packages don't have to worry about manually removing the pre packages to get the real ones. I will collapse the pre packages into one changelog entry for the -1 release. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Warren Turkal wrote: Version of your package results in a lintian warning, because your version string is not like it should be in Debian. Your version should be foo-x.x.x (another .x is for NMUs). I want the package to be sorted before a real -1 release in the debian archive so that folks installing the pre packages don't have to worry about manually removing the pre packages to get the real ones. I will collapse the pre packages into one changelog entry for the -1 release. You can use the ~ suffix, as in 3.6.2-beta4~pre1. These versions will evaluate lower than 3.6.2-beta4. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 12:35, Felipe Sateler wrote: You can use the ~ suffix, as in 3.6.2-beta4~pre1. These versions will evaluate lower than 3.6.2-beta4. Thanks for the info. I am guessing that I would version it like 3.6.2-beta4~pre1-1 then? wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal [EMAIL PROTECTED] wrote: Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Ugh, what's this 'tex' package? Before blindly doing what others tell you, you'd better think a little bit (I'm sure Patrick didn't want to deceive you; just to make you think about which package(s) to Build-Depend on in order to get your texi2dvi call running properly). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 14:33, Florent Rougon wrote: Warren Turkal [EMAIL PROTECTED] wrote: Okay, the build deps now look like: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi Ugh, what's this 'tex' package? Well, I haven't posted the new version of the package because I haven't tested all the changes yet. I just wanted to respond to the email more timely than waiting for the next posting of my package, which could happen this evening. I will check more into this issue this evening. Here is the current Build-Depends line: Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, texinfo It is running through debuild-pbuilder right now. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Monday 11 December 2006 15:33, Warren Turkal wrote: It is running through debuild-pbuilder right now. New version (3.6.2-beta4~pre1) at [1]. This version sorts before the last one so you will have to manually remove the prior packages I posted if you used apt* to install them. Here's the changelog entry. netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) * Combined all libs into one package. * Upstream version fixes inconsistent manpage (closes: #353332) * Touched up descriptions on some of the packages wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
