Re: RFS: knetstats
Hi Daniel, Daniel Baumann wrote: but now, you've added additional stuff which you have successfully removed previously: * useless commented docbook-to-man call in rules Okay!! Fixed. * not required dh_* calls I don't know which dh_ call you're pointing to. I've not changed any of those calls. And I don't see any commented dh_ call there. i'm wondering if you can't fix one thing and let the rest as it was :)) Still learning. :-) Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. Stealing logic from one person is plagiarism, stealing from many is research. The great are those who achieve the impossible, the petty are those who cannot - rrs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Help regarding package with shared objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you are able to help me with some problems I am having packaging an application with some shared objects (.so libraries), I would be very grateful. I know very little about SOs, and even after a bit of research on the web I'm still not sure of the best way to proceed. I'm packaging AFNIX which delivers some executables and a set of shared objects that the executables use. 1) The upstream makefile compiles the SOs into /usr/local/lib, which I will obviously need to change for Debian. As the SOs are only used by the AFNIX executables, would it be best to put the SOs in their own directory, e.g. /usr/lib/afnix ? If so is that just a case of passing - -rpath parameters to the linking stage? 2) As the SOs are only used by the AFNIX executables, is it OK to create just one binary package? I don't see much advantage in separating out a -dev package - do you agree? Thanks, Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgSijLSXFtdTZVSURAqw6AJ9q98YkxrVHB5I/Rvpi9kzf5yow8ACfdi7j ZzL7zNQ4KsH60kaN2KF+buY= =Opp3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help regarding package with shared objects
Hi Paul, you should definitely read http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html It should answer most of your questions, including package layout and the role of -dev packages. Regarding the install location: does your package use autoconf? You then probably simply need to pass a --prefix=/usr parameter to the configure script to install it in the proper places. Otherwise you might need to further examine the build and install mechanism of your package ... Don't know about your general Debian packaging knowhow, but some other must reads are: http://www.debian.org/doc/devel-manuals#maint-guide http://www.debian.org/doc/devel-manuals#devref http://www.debian.org/doc/debian-policy/ Regards, Andreas Paul Cager wrote: If you are able to help me with some problems I am having packaging an application with some shared objects (.so libraries), I would be very grateful. I know very little about SOs, and even after a bit of research [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
changelog entries - ubuntu?
During a recent upgrade of my Debian Sid box, I noticed the following changelog entry: f-spot (0.2.2-0ubuntu1) feisty; urgency=low * Update to 0.2.2 upstream Perhaps I've already missed a discussion on this. If so, I'd appreciate a link/pointer so that I can read up. But if not, then are their guidelines or policy statements somewhere that explain how and when Ubuntu releases are incorporated into Debian? I maintain a handful of Debian packages and am genuinely curious about this and am not trying to start a heated debate. Thanks, Kevin -- Kevin Coyner GnuPG key: 1024D/8CE11941 signature.asc Description: Digital signature
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: Homepage-field in description
On 12/14/06, Russ Allbery [EMAIL PROTECTED] wrote: Does the Lintian issua an information message of any kinf for the Homepage: field? If it would, the maintainers could possibly pay more attention. Not many are aware of the spcae or two space reason for long URLs. No. There's a proposed patch that I'm not horribly happy with because I'm worried that it's too aggressive, and I haven't had a chance to think more about it and revisit it. I'm planning on preparing a patch for dpkg to add the Homepage field to the control fields of the package. Will most probably work on this during the summer [1]. Maybe then we can stop the stupid one space vs two spaces fight. [1]: My Southern-Hemisphere Summer, which is almost starting :) -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog entries - ubuntu?
Kevin Coyner wrote: During a recent upgrade of my Debian Sid box, I noticed the following changelog entry: f-spot (0.2.2-0ubuntu1) feisty; urgency=low * Update to 0.2.2 upstream Perhaps I've already missed a discussion on this. If so, I'd appreciate a link/pointer so that I can read up. But if not, then are their guidelines or policy statements somewhere that explain how and when Ubuntu releases are incorporated into Debian? I maintain a handful of Debian packages and am genuinely curious about this and am not trying to start a heated debate. Hi Kevin, (another Kevin here) I am pretty sure there is no formal policy describing what to do about version numbers containing the substring ubuntu (or that of any other derived distribution). As far as I can see, in practice having ubuntu entries in the Debian changelog is tolerated. This commonly happens when the Debian and Ubuntu maintainers are the same persons, or the Debian maintainers pull from the Ubuntu maintainer's work. I imagine that having a version number containing ubuntu in the actual package uploaded to Debian is discouraged. I only found one package in Sid at the moment that does this: update-manager, version 0.42.2ubuntu22-7. I think this is because Ubuntu is upstream for this package. 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: changelog entries - ubuntu?
On Thu, 14 Dec 2006 07:13:19 -0500 Kevin Coyner [EMAIL PROTECTED] wrote: During a recent upgrade of my Debian Sid box, I noticed the following changelog entry: f-spot (0.2.2-0ubuntu1) feisty; urgency=low * Update to 0.2.2 upstream Perhaps I've already missed a discussion on this. If so, I'd appreciate a link/pointer so that I can read up. But if not, then are their guidelines or policy statements somewhere that explain how and when Ubuntu releases are incorporated into Debian? I maintain a handful of Debian packages and am genuinely curious about this and am not trying to start a heated debate. Not all Ubuntu changes are relevant to the Debian usage. At other times, the Ubuntu patch can help significantly with bug reports against the Debian package. In some ways, the Ubuntu changes become a bit like an NMU and you need to acknowledge any changes that you integrate into the Debian package. You are best placed to check the patch. You should be able to tell quite quickly whether the Ubuntu changes are worth integrating into the Debian package. If the ubuntu changes aren't relevant, you can ignore Ubuntu releases. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpLAcjXe5fRT.pgp Description: PGP signature
Re: changelog entries - ubuntu?
Neil Williams [EMAIL PROTECTED] writes: In some ways, the Ubuntu changes become a bit like an NMU and you need to acknowledge any changes that you integrate into the Debian package. Yes, I saw a 'Patch from ubuntu' against my package 'flexbackup' (it didn't come in as a bug, but it's on the package tracking overview in the 'Patches' section. http://packages.qa.debian.org/f/flexbackup.html It seemed to me that one resolution would be to treat it just like an NMU and include the ubuntu changelog entries in my changelog, topped with an entry acking the patch and making the upload. OTOH, maybe it would be better not to include the ubuntu changelog entries (since they don't conform to Debian practice regarding distribution) and just summarize the changes with an ack in my changelog entry. What would be the offical pronouncement on this? -- KBK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog entries - ubuntu?
On Thu, 14 Dec 2006 15:17:26 -0500 Kurt B. Kaiser [EMAIL PROTECTED] wrote: In some ways, the Ubuntu changes become a bit like an NMU and you need to acknowledge any changes that you integrate into the Debian package. Yes, I saw a 'Patch from ubuntu' against my package 'flexbackup' (it didn't come in as a bug, but it's on the package tracking overview in the 'Patches' section. http://packages.qa.debian.org/f/flexbackup.html That patch appears to add significant functionality to the package - you should at least consider this as a wishlist bug, tagged as + patch and deal with it appropriately. If you feel you would like more information on how this functionality is useful within Ubuntu, open a wishlist bug yourself and CC: the Ubuntu maintainer mentioned in the changelog in the patch. I'd expect that he (Michael Bienia) would be only to happy to discuss the patch. It seemed to me that one resolution would be to treat it just like an NMU and include the ubuntu changelog entries in my changelog, topped with an entry acking the patch and making the upload. Yes, if the new functionality is something you feel confident to implement and support within Debian, this would be, IMHO, an appropriate method to handle the patch. OTOH, maybe it would be better not to include the ubuntu changelog entries (since they don't conform to Debian practice regarding distribution) and just summarize the changes with an ack in my changelog entry. Changelog entries - yes those can be reformatted - it would be polite, I think, to include the main text of each log entry along with the details of who and when in a changelog entry of your own in debian/changelog. This way you can acknowledge and thank the Ubuntu maintainer for his patch. What would be the offical pronouncement on this? It sounds like there isn't an official position on this, it's left to individual maintainers to judge the appropriateness of the Ubuntu changes and decide whether or not to pass on any new functionality to Debian. If this is done, then it is only polite to acknowledge the source of the patch. Also, consider dropping a line to upstream - if this functionality is not already documented in the upstream code - so that everyone else can benefit. There's no reason for such actions to be limited to Ubuntu either - if you become aware that Fedora or Mandriva implement the same upstream source with added or less buggy support for X feature, it's only sensible to bring those changes into Debian as well as ensuring that upstream know about the changes and are given a chance to support them upstream. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpfbRYssEY1m.pgp Description: PGP signature
Re: changelog entries - ubuntu?
On Thu, Dec 14, 2006 at 07:13:19AM -0500, Kevin Coyner wrote: During a recent upgrade of my Debian Sid box, I noticed the following changelog entry: f-spot (0.2.2-0ubuntu1) feisty; urgency=low * Update to 0.2.2 upstream Perhaps I've already missed a discussion on this. If so, I'd appreciate a link/pointer so that I can read up. But if not, then are their guidelines or policy statements somewhere that explain how and when Ubuntu releases are incorporated into Debian? Information for Debian developers about Ubuntu can be found here: https://wiki.ubuntu.com/UbuntuForDebianDevelopers If there's an appropriate place in the Debian wiki or documentation to link to this, I'd appreciate that. The short answer is that it's up to the individual maintainer how and when they incorporate changes. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
