Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On 09/10/2007 06:40 PM, Justin Pryzby wrote : Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Now after trying to split the libraries, trying to figure out correct dependecies and having run into several lengthy problems, I discussed a bit more with upstream. Upstream's (very strong) opinion is, that it is useless to split the big library package into its parts. These are really useless for themselves. In the future (Gwyddion 3.x), the libraries will be reorganized, to allow separate use. But until then, it seems best to keep them together. The sonames of the parts will not be changed independently, in fact, they'll stay at .0 during all the 2.x series of Gwyddion). So I would like to make use of the policies may (you may lump them all together into a single shared library package) and keep the libraries in one package. Are you, Justin, willing to sponsor this package then, or should I retry with an updated RFS? Best Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Tue, Sep 18, 2007 at 11:19:04AM +0200, Jan Beyer wrote: On 09/10/2007 06:40 PM, Justin Pryzby wrote : Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Are you, Justin, willing to sponsor this package then, or should I retry with an updated RFS? Sorry, not a DD, so I can't sponsor you. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software (2nd attempt)
Hi Jan, I am basically off for the next two weeks but volunteer to sponsor you when I return at the end of this month - should you not have found someone else. Please consider to join the Debian-Med folks at http://www.us.debian.org/devel/debian-med/ there may be someone available earlier than me. Cheers, Steffen On Tuesday 18 September 2007 14:11:02 Jan Beyer wrote: Dear mentors, I am looking for a sponsor for my package gwyddion. * Package name: gwyddion Version : 2.8-1 Upstream Authors: David Nečas (Yeti) [EMAIL PROTECTED], Petr Klapetek [EMAIL PROTECTED] and more * URL : http://gwyddion.net/ * License : GPL-v2+, and parts PD Section : science It builds these binary packages: gwyddion - Scanning Probe Microscopy (SPM) analysis software Gwyddion is a modular program for Scanning Probe Microscopy (SPM) data visualization and analysis. It is primarily intended for analysis of height field obtained by SPM techniques like AFM, MFM, STM, SNOM/NSOM etc. It can, however, be used for any other height field and image analysis. gwyddion-common - Gwyddion SPM analysis software - common files gwyddion-plugins - Gwyddion SPM analysis software - plugins libgwyddion2-0 - Gwyddion SPM analysis software - libraries libgwyddion20-dev - Gwyddion SPM analysis software - header files and static libraries libgwyddion20-doc - Gwyddion SPM analysis software - HTML library API documentation The lintian errors are taken care of by an override file[1]. The package seems to be pbuilder clean. The piuparts (-d sid) output shows some error, which may be unrelated to gwyddion[2]. You may find a discussion of the original RFS in the mailing list archive[3]. ITP: 440662 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gwyddion - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gwyddion/gwyddion_2.8-1.dsc I would be glad if someone uploaded this package for me. Kind regards Jan Beyer Annotations: [1] The errors are about some python/ruby scripts, which are in the gwyddion package, which does not depend on the interpreters. This is due to the fact, that the package shall only provide some basic guaranteed infrastructure for plugins, which users may want to use/write. But Gwyddion itself does not use/need the interpreters. The same lintian message is emitted for the gwyddion-plugins package. There I added the Depends: python | perl | ruby line, which lintian doesn't seem to understand. Furthermore there is a lintian warning, concerning the libgwyddion2-0 package, which is actually a bundle of libraries. These cannot usefully be split into single-library packages, as the libraries themselves are not well split with regard to their functions/symbols (according to upstream), so nobody will want to link against only one of them. [2] Piuparts (-d sid) brings up some broken symlinks in /var/lib/defoma/fontconfig.d/D and related to pico. But as gwyddion has nothing to do with this, it may be, that this is unrelated to gwyddion. piuparts -d etch runs fine. [3] http://lists.debian.org/debian-mentors/2007/09/msg00161.html No sponsor was found there. I fixed the dependency problem. Now gwyddion Depends: libgwyddion2-0 (= 2.8-1). Thank you very much for reading until here! signature.asc Description: This is a digitally signed message part.
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Sat, Sep 08, 2007 at 08:24:19PM +0200, Jan Beyer wrote: Justin Pryzby schrieb am 07.09.2007 17:46 Uhr: On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Thank you very much for reading until here! Any comments (also on different topics) are very much welcome! Thank you for doing the packaging! I didn't know about the program before, I just tried your .deb and it looks very good (both the packaging and gwyddion). I am looking forward when you resolve the rest of technical issues and it hits unstable. I'll point it out to my colleagues in Prague who use windows and proprietary programs for processing AFM images, to try gwyddion out. Just curious - what is Czech Metrology Institute using scanning probe microscopy techniques for? I always thought metrology institutes are predicting weather. :) Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Justin Pryzby schrieb am 07.09.2007 17:46 Uhr: On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the snip So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). The point is, at least as upstream explained to me, that these libraries are not particularly well split with regard to their contents. So no one will link against just one or some of them. In fact, one often needs some modules (which are in the gwyddion package) to build something reasonable. That's why I/we (we=upstream+me) decided to put them together. Concerning putting them into subdirectories: This would mean creating a subdirectory for each library and putting it in there? Could I then keep them all in one package? The directory would be named after the package. /usr/lib/libgwyddion2/* and either the public libraries or final binaries would need rpath to find them. (It still seems a grey area whether to add a soname and install the lib to /usr/lib or to use rpath for some things). hmmm, then simply splitting the library package sounds easier... ;-) And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. Unfortunately my Linux-installation is screwed up at the moment :-(, but I'll work on it as soon as I get it fixed (hopefully during the coming week). Do you have any comments on this Depends: python | perl | ruby line? Is it allowed and does it work like one would expect it? Do you prefer the next package version to be 2.8-2 or should it stay 2.8-1 (there seems to be no real consensus about this)? Many thanks! Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Ondrej Certik schrieb am 08.09.2007 14:04 Uhr: Thank you very much for reading until here! Any comments (also on different topics) are very much welcome! Thank you for doing the packaging! I didn't know about the program before, I just tried your .deb and it looks very good (both the packaging and gwyddion). I am looking forward when you resolve the rest of technical issues and it hits unstable. I'll point it out to my colleagues in Prague who use windows and proprietary programs for processing AFM images, to try gwyddion out. Thanks! This is very much welcome, of course! Just curious - what is Czech Metrology Institute using scanning probe microscopy techniques for? I always thought metrology institutes are predicting weather. :) Ondrej Probably Petr Klapetek [EMAIL PROTECTED] is the right one to ask in this question. But you're right - it's an interesting question, which I did not yet ask them... ;-) Have a nice weekend, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
David Necas (Yeti) [EMAIL PROTECTED] schrieb am 08.09.2007 20:38: On Sat, Sep 08, 2007 at 08:34:31PM +0200, Jan Beyer wrote: Probably Petr Klapetek [EMAIL PROTECTED] is the right one to ask in this question. But you're right - it's an interesting question, which I did not yet ask them... ;-) Quoting my reply to Ondrej: Metrology institutes define the measurement standards so that you can compare the lengths of metrology and meteorology and find that the latter is 22.2% longer... shame on me, that I missed these 22.2%... I shouldn't be trying to read and write mail in the evening with a headache and fever... Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Metrology institutes define the measurement standards so that you can compare the lengths of metrology and meteorology and find that the latter is 22.2% longer... shame on me, that I missed these 22.2%... I shouldn't be trying to read and write mail in the evening with a headache and fever... Shame on me as well. But now I think I will never mistake metrology and meteorology again, that's what debian-mentors is for, right? :) O. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Dear mentors, I am looking for a sponsor for my package gwyddion. * Package name: gwyddion Version : 2.8-1 Upstream Author : David Nečas (Yeti) [EMAIL PROTECTED], Petr Klapetek [EMAIL PROTECTED] * URL : http://gwyddion.net/ * License : GPL-v2+, and parts PD Section : science It builds these binary packages: gwyddion- Scanning Probe Microscopy (SPM) analysis software Neat :) (Long) Annotations (=Request for Help/Comment/Explanation): Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the warning? Override it? Split the package (This seems useless to me)? Policy has this to say: |If you have several shared libraries built from the same source tree |you may lump them all together into a single shared library package, |provided that you change all of their sonames at once (so that you |don't get filename clashes if you try to install different versions of |the combined shared libraries package). The goal is that debs compiled/depending against any libgwyddion* libraries are always installable (well, the other goal is that there are only 2 versions of a library in the active archive at once). So you have to avoid the situation where libgwyddion2 includes: libxyza.so.1 and libxyzb.so.1, and the as-of-yet hypothetical libgwyddion3 includes libxyza.so.1 and libxyzb.so.2 (thus the new package name). In this case lib3 is required to Conflict on lib2 (or the other way around) since they're not actually co-installable. But then every package compiled against lib2 will end up effectively conflicting with every package compiled against lib3 since it's impossible to satisfy the packages of any 2 such packages. So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
Many thanks for the quick response! On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the snip So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). The point is, at least as upstream explained to me, that these libraries are not particularly well split with regard to their contents. So no one will link against just one or some of them. In fact, one often needs some modules (which are in the gwyddion package) to build something reasonable. That's why I/we (we=upstream+me) decided to put them together. Concerning putting them into subdirectories: This would mean creating a subdirectory for each library and putting it in there? Could I then keep them all in one package? I have no idea, whether this will be hard to achieve or cause problems - I can ask upstream, if you would prefer this solution. But then it would probably be easier to just split libgwyddion2 into the six single-library-packages... And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: Many thanks for the quick response! On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the snip So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). The point is, at least as upstream explained to me, that these libraries are not particularly well split with regard to their contents. So no one will link against just one or some of them. In fact, one often needs some modules (which are in the gwyddion package) to build something reasonable. That's why I/we (we=upstream+me) decided to put them together. Concerning putting them into subdirectories: This would mean creating a subdirectory for each library and putting it in there? Could I then keep them all in one package? The directory would be named after the package. /usr/lib/libgwyddion2/* and either the public libraries or final binaries would need rpath to find them. (It still seems a grey area whether to add a soname and install the lib to /usr/lib or to use rpath for some things). And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
