RFS: gwyddion - Scanning Probe Microscopy analysis software
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 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 - Gwyddion SPM analysis software - libraries libgwyddion2-doc - Gwyddion SPM analysis software - HTML library API docs libgwyddion2-dev - Gwyddion SPM analysis software - Development files 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]. The upload would fix these bugs: #440662. The package can be found here: - URL: http://people.ifm.liu.se/beyer/gwyddion - dget http://people.ifm.liu.se/beyer/gwyddion/gwyddion_2.8-1.dsc I would be glad if someone gave comments on the problems outlined below and later uploaded this package for me. Kind regards Jan Beyer (Long) Annotations (=Request for Help/Comment/Explanation): [1] lintian-overrides: The errors consist of some python/ruby scripts, which are in the gwyddion package, which does not depend on the interpreters. This is due to the fact, that these only provide some basic guaranteed infrastructure for plugins, users may want to use/write. But they are not used/needed by anything inside the package. The same lintian message is emitted for the gwyddion-plugins package. There I added the Depends: python | perl | ruby line. I do not know, if this construct is allowed and works, but only lintian doesn't recognize it, or if it is not possible. Then I would have to change the line to Depends: python, perl, ruby. 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)? There is also a warning on a man(3) file, called Gwyddion::dump.3pm.gz, which lintian seems to dislike as the section is != 3. But there are many similar files in my /usr/share/man/man3 directory. What to do here? 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? [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. Thank you very much for reading until here! Any comments (also on different topics) are very much welcome! -- 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: cellwriter
On Fri, 07 Sep 2007, Cyril Brulebois wrote: Michael Levin [EMAIL PROTECTED] (06/09/2007): You know, that bugs can be merged? I got an email from BTS saying the two reports were merged by someone already. However, they both still show up in the bugs list and I'm not sure which bug number they were merged into so I'm leaving the ChangeLog as is. They are merged, fullstop. No “master” bug or “duplicates”, just close both in the changelog and you're done. You don't even need to close both. Just close whichever one you feel like closing and the other will be closed as well. Don Armstrong -- [A] theory is falsifiable [(and therefore scientific) only] if the class of its potential falsifiers is not empty. -- Sir Karl Popper _The Logic of Scientific Discovery_ §21 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: RFS: libj2ssh-java
On Thu, 06 Sep 2007, tony mancill wrote: Can you provide any generic guidelines on how large the docs should be to warrant a separate -doc package? This comes up from time to time sponsoring, and for new packages I've seen packages rejected because the -doc package was too small. The general rule is the -doc package should be large enough that its presence significantly impacts either the mirror or the installed size of the package *or* would legitimately have a dependency relationship (recommends, suggests, etc.) without including the non-doc packages. An Arch: all non-doc package(s) needs a bigger -doc package to counteract the package list size increase than an Arch: any package. If the -doc package is at least on the order of a megabyte and a significant portion of the size of the non-doc package(s), there's generally little question about splitting it out. If it's less than 200K, or an insignificant portion of the non-doc package, there's generally little point. Most of the time it's pretty obvious. If it's not, err on the side of not making an extra package, but make one if your users file a bug. Don Armstrong -- Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xournal (updated package)
Hi, Since my mentor for xournal decided to stop sponsoring packages, I am in search of a new mentor for xournal which is already in debian. Upstream has released an update to xournal (0.3.3 - 0.4.0.1). This is the updated debian package. This release includes a lot of improvements. The hand tool, for example, has been asked by a lot of people (I already received an email from an user asking when the update will be integrated). I also added menu and mimetype informations for both GNOME and KDE. See upstream ChangeLog for more informations. The package appears to be lintian clean, except from some warnings about the desktop file x-xoj.desktop, which contains deprecated .desktop specification elements to add support for kde mimetypes (this is required since kde 3.x doesn't support shared-mime-info). The upload would fix these bugs: 410909 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xournal - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xournal/xournal_0.4.0.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Mathieu Bouchard Centre de bio-informatique (www.bioinfo.ulaval.ca) Université Laval (Québec, Canada) Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
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]
RFS: glchess (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0.6+debian-1 of my package glchess. It builds these binary packages: glchess- 2D/3D chess interface The package appears to be lintian clean. The upload would fix these bugs: 421694, 441156 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/glchess - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/glchess/glchess_1.0.6+debian-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Thierry Randrianiriana signature.asc Description: OpenPGP digital signature
Re: DebPPA: Debian Personal Package Archive
Many Debian packages aren't designed to support cross-compilation. Currently the only way to reliably build for multiple architectures is to build on multiple architectures. I just found a qemubuilder packages, from the same author as pbuilder and cowbuilder and can build packages for different platforms using qemu. That's awesome. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xournal (updated package)
On Fri, Sep 07, 2007 at 08:10:11AM -0400, Mathieu Bouchard wrote: Hi, Hi... I will review and sponsor (maybe) your package tomorrow. Thanks for your work and regards, enjoy your weekend, -- .''`. Mario Iseli [EMAIL PROTECTED] : :' :Debian GNU/Linux developer `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: zimpl (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.07.ds1-1 of my package zimpl. Usually, Anibal Monsalve Salazar sponsors the package, but I haven't got a reply for a few days, so I assume he is busy right now. It builds these binary packages: zimpl - mathematical modeling language for optimization problems The package is lintian and linda clean and builds fine with pbuilder. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/z/zimpl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/z/zimpl/zimpl_2.07.ds1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Joachim Reichel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some help needed for kernel-module and m-a
Hi, I'm currently debianizing oracleasm. Till now quite some things look pretty well. They point where I'm lost it the module-assistant build. When I install the oracleasm-source_2.0.4-1_all.deb package it unpacks /usr/src/oracleasm.tar.bz2 correctly. After that I want to build the module using m-a a-b oracleasm Everything seems to be build correctly BUT instead of building a oracleasm-kernel-whatever it generates a oracleasm-source_2.0.4-1+2.6.18.dfsg.1-13etch2_all.deb which is again the same package name as the module-source. Also the package does not contain the .ko file although it had been build under /usr/src/modules/oracleasm/debian/oracleasm-kernel-2.6.18-5-vserver-amd64/lib/modules/2.6.18-5-vserver-amd64/misc/oracleasm.ko Might anybody have a look on my try to find the hint I'm missing? The sources and all is available via http://jesusch.de/~jesusch/debian/ thnx in advance Bjoern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some help needed for kernel-module and m-a
On Friday 07 September 2007 21:22:28 Bjoern Boschman wrote: Hi, I'm currently debianizing oracleasm. Till now quite some things look pretty well. They point where I'm lost it the module-assistant build. When I install the oracleasm-source_2.0.4-1_all.deb package it unpacks /usr/src/oracleasm.tar.bz2 correctly. After that I want to build the module using m-a a-b oracleasm Everything seems to be build correctly BUT instead of building a oracleasm-kernel-whatever it generates a oracleasm-source_2.0.4-1+2.6.18.dfsg.1-13etch2_all.deb which is again the same package name as the module-source. Also the package does not contain the .ko file although it had been build under /usr/src/modules/oracleasm/debian/oracleasm-kernel-2.6.18-5-vserver-amd64/l ib/modules/2.6.18-5-vserver-amd64/misc/oracleasm.ko Might anybody have a look on my try to find the hint I'm missing? The sources and all is available via http://jesusch.de/~jesusch/debian/ thnx in advance Bjoern Hi I remember making the same mistake :) The trick is in the control.modules.in file. Is it possible to see your package. Then I (or some other) might be able to find the error. Cheers Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cellwriter
Hi Michael! On 9/7/07, Michael Levin [EMAIL PROTECTED] wrote: Also, your debian/copyright is basically empty and (maybe) you need to review debian/rules. Fixed the copyright. The rules file works fine as far as I can tell. I know that it's working, but I only asked because of this line on debian/rules: # Add here any variable or target overrides you need. As a suggestion, remove this line. It's not necessary to install README (this info is already on the package description and on the manpage). AUTHORS is also included on debian/copyright, so I don't see a need to install it too. I strongly recommend to you create a debian/menu file. All the files inside your tarball have the execution bit set. It's not need to have all the files executable (just a suggestion for your next release). And I have tested cellwriter and it's not working :-( While training its input, the letters don't get darker with training. Any ideas why it's happening? Best regards, Nelson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xournal (updated package)
Thanks, I will wait for your comments -- Mathieu Bouchard Centre de bio-informatique (www.bioinfo.ulaval.ca) Université Laval (Québec, Canada) Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
