Re: RFS: libmemcached
On Thu, May 21, 2009 at 23:37, Monty Taylor wrote: > LI Daobing wrote: >> Hello, >> >> On Wed, May 20, 2009 at 08:30, LI Daobing wrote: >>> On Wed, May 20, 2009 at 05:27, Monty Taylor wrote: Hi! libmemcached 0.29 was released today, so I have uploaded a new package version to mentors. It also adds a -dbg package closing #529285. If you have a chance, could you take a look at it for me? >>> consider always post the .dsc URL. >>> >>> I'll look at it >>> >> dget >> http://mentors.debian.net/debian/pool/main/l/libmemcached/libmemcached_0.29-1.dsc >> >> one issue, not lintian clean: >> $ lintian libmemcached_0.29-1_amd64.changes >> W: libmemcached-dbg: wrong-section-according-to-package-name >> libmemcached-dbg => debug > > Whoops. I had fixed that and not uploaded it. :) > > New version uploaded. > uploaded. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Swig and Java bindings packaging
(please don't cc me) Dmitrijs Ledkovs wrote: > 2009/5/22 Felipe Sateler : >> Dmitrijs Ledkovs wrote: >> >>> I'm maintaining a C++ library. They have SWIG (python) and Java (dunno >>> how) bindings which are not packaged right now. >>> >>> I would greatly appreciate if someone can point out good examples of >>> packaged python-swig and / or Java bindings for libraries? >>> >>> I'm a bit stuck cause the bindings are not integrated into autofoo >>> build system (it's not just additional flag to configure) and i >>> struggling to get my head around how to link against a library which >>> has just been build and not yet installed. >>> >> >> SWIG is an interface generator for C++ into several languages. So >> probably both interfaces in your program are SWIG-based. >> >> If the interfaces are not hooked into the package build system, then you >> will probably have to invoke swig directly to generate them. My package >> csound uses SWIG to generate Java, Python and Lua bindings. It uses >> scons, however. >> What package is this? >> >> -- >> Felipe Sateler >> > > It's libsword7 (currently only in experimental) Hmm, I can't figure out what upstream was doing with the build system for the bindings. I think you should contact them and ask about the correct way to build the bindings. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Updated packge on m.d.n
Dear John, John Stamp schrieb: > On Friday 22 May 2009 11:12:36 am Kai Wasserbäch wrote: >> an updated package of kde-plasmoid-yawp has been uploaded to >> mentors.debian.net, the new dgetable URL is: >> http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-pl >> asmoid-yawp_0.2.3-2.dsc > > I'm not a DD, but I have a few comments about the packaging... your feedback is appreciated anyway. So thank you for your time. > dpkg-shlibdeps_fix_spurious_dependencies.patch: > > Why not add pkg-kde-tools to your Build-Depends? You can set > DEB_KDE_LINK_WITH_AS_NEEDED, plus you'll be using the same cmake setup > that all of the other KDE packages use. Thanks for pointing this out, I only remembered some cdbs snippets in pkg-kde-tools and therefore didn't consider having a closer look into it. Dropped the patch, replaced by the proper variables from variables.mk > licensecheck_incorrect_FSF_address.patch: > > I don't think we have the right to change upstream's copyright notice > for them. Send *them* the patch instead. They're pretty responsive--or > have been with the few patches that I sent. I've already sent the patch to them and informed them of the ITP so they might advocate the Debian package in due time (should it be accepted). But I don't consider correcting a wrong postal address »changing the license«. I see it merely as a convenience for interested people who want to write to the FSF for further information. Even if I don't think most people care about the postal address. Patch kept. > top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch: > > This patch seems to fix a problem that does not exist. You probably > don't even need to restrict to kdelibs5-dev (>= 4:4.2.0). Or am I > missing something? I certainly see your point and have therefore removed the patch. The rationale was to save time on the buildds (even though that is probably a very small amount of time) for a check where I know the result already in advance. The restriction is kept in place though: I don't think this Plasmoid works well with KDE 3.5 and a version of the kdelibs5 was included in Lenny. So I consider this a kind of warning to potential backporters (I have no idea whether that will happen anyway, I doubt it, but maybe someone with some experience in this field can give me a tip.) > README.Debian: > > I'd remove it. It just duplicates info found in the description. I concur. It's a vestige of the original README.Debian file I'd written before putting the package under VCS control. Even though I wonder why it lacked the better part of the originally intended file. I must have imported some »ancient« version. Thanks for pointing it out to me, I might have overlooked it for quite some time. ;) A modified package can be found in the SVN [0] and will soon be available as 0.2.3-3 as a source package from m.d.n but maybe I can get some more feedback before that. :) Kind regards, Kai Wasserbäch [0] svn://svn.carbon-project.org/deb-pkg/kde-plasmoid-yawp/trunk -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: deb...@carbon-project.org Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex) signature.asc Description: OpenPGP digital signature
Re: Updated packge on m.d.n (was: RFS: kde-plasmoid-yawp)
On Friday 22 May 2009 11:12:36 am Kai Wasserbäch wrote: > Dear mentors, > an updated package of kde-plasmoid-yawp has been uploaded to > mentors.debian.net, the new dgetable URL is: > http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-pl >asmoid-yawp_0.2.3-2.dsc I'm not a DD, but I have a few comments about the packaging... dpkg-shlibdeps_fix_spurious_dependencies.patch: Why not add pkg-kde-tools to your Build-Depends? You can set DEB_KDE_LINK_WITH_AS_NEEDED, plus you'll be using the same cmake setup that all of the other KDE packages use. licensecheck_incorrect_FSF_address.patch: I don't think we have the right to change upstream's copyright notice for them. Send *them* the patch instead. They're pretty responsive--or have been with the few patches that I sent. top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch: This patch seems to fix a problem that does not exist. You probably don't even need to restrict to kdelibs5-dev (>= 4:4.2.0). Or am I missing something? README.Debian: I'd remove it. It just duplicates info found in the description. Regards, John Stamp -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: pytemplate
Ignace Mouzannar writes: > python-pytemplate - Python template framework This seems a misleading synopsis. It implies a generic templating system implemented in Python. When composing an RFS, it's usually best to give the full description as well. Can you show that to us in this thread? -- \“With Lisp or Forth, a master programmer has unlimited power | `\ and expressiveness. With Python, even a regular guy can reach | _o__) for the stars.” —Raymond Hettinger | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: iguanair
Hello and thank you for the review, On Friday 22 May 2009, Paul Wise wrote: > 2009/5/22 Stefanos Harhalakis : > > iguanair - IguanaWorks IR daemon/driver > > iguanair-python - IguanaWorks IR python bindings > > Should be python-iguanair. Fixed. > > iguanair-reflasher - IguanaWorks IR reflasher utility > > libiguanair - IguanaWorks IR support library > > Package name should contain the SONAME/ABI number, details in the > libpkg-guide (please read the two bugs on it too). I believe I fixed it. Following the instruction of libpkg-guide I changed the libiguanair package to libiguanair0 (which matches the SONAME). From what I've read on one of the bug reports, I understand that the correct naming for -dev is libiguanair-dev so I left it as-is. The new version is in mentors using the same version: - URL: http://mentors.debian.net/debian/pool/main/i/iguanair - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/iguanair/iguanair_0.99-1.dsc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Updated packge on m.d.n (was: RFS: kde-plasmoid-yawp)
Dear mentors, an updated package of kde-plasmoid-yawp has been uploaded to mentors.debian.net, the new dgetable URL is: http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-plasmoid-yawp_0.2.3-2.dsc I cite the changelog: > * debian/control: > - Declare explicit Build-Depend on gettext. > - Tighten Build-Depends on kdelibs5-dev: enforce version >=4:4.2.0 > - Added quilt to Build-Depends. > - Added Vcs-Svn field. > - Improved long description. > * CMakeLists.txt: > - Remove unneeded if-else-statement, we know for sure that we have KDE 4.2 > around (for further details see the patch header). > (Patch: top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch) > - Ensure minimal linking (for further details see the patch header). > (Patch: dpkg-shlibdeps_fix_spourious_dependencies.patch) > * debian/rules: > - Add new patch and unpatch targets, using dh_quilt_{,un}patch. The new long description is: > A nice and simple plasmoid for KDE 4.x to show the weather forecast, works > with > AccuWeather and Google Weather (planned). You can configure it to show several > days in advance and to display the current satellite image. > > Could be considered to be a replacement for the SuperKaramba script > »LiquidWeather++«. If you should need further information please have a look at the ITP [0], where all information is aggregated. Thank you in advance for your time and effort! Kind regards, Kai Wasserbäch [0] http://bugs.debian.org/529815 -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: deb...@carbon-project.org Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex) signature.asc Description: OpenPGP digital signature
Re: RFS: iguanair
2009/5/22 Stefanos Harhalakis : > iguanair - IguanaWorks IR daemon/driver > iguanair-python - IguanaWorks IR python bindings Should be python-iguanair. > iguanair-reflasher - IguanaWorks IR reflasher utility > libiguanair - IguanaWorks IR support library Package name should contain the SONAME/ABI number, details in the libpkg-guide (please read the two bugs on it too). -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: pytemplate
Dear mentors, I am looking for a sponsor for my package "pytemplate". * Package name: pytemplate Version : 1.5.1-1 Upstream Author : Stéphane Bulot * URL : http://www.bulot.org/wiki/doku.php?id=projects:python:pytemplate * License : GPL-3 Section : python It builds these binary packages: python-pytemplate - Python template framework The package appears to be lintian clean. The upload would fix these bugs: 529609 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pytemplate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pytemplate/pytemplate_1.5.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ignace Mouzannar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: iguanair
Dear mentors, I am looking for a reviewer and a sponsor for my package "iguanair". * Package name: iguanair Version : 0.99-1 Upstream Author : IguanaWorks Inc. * URL : http://iguanaworks.net/ * License : GPLv2 and LGPLv2 Section : utils It builds these binary packages: iguanair - IguanaWorks IR daemon/driver iguanair-python - IguanaWorks IR python bindings iguanair-reflasher - IguanaWorks IR reflasher utility libiguanair - IguanaWorks IR support library libiguanair-dev - IguanaWorks IR development files This package adds support for the IR transceiver made by iguanaworks. They have pretty good support and are additional seem to be promoting opensource with their activities. This upload will also help resolve bug #524403. This is the first package that with I'm doing from scratch that also has a library, support files and python bindings, so it desperately needs a review. The package appears to be lintian clean except from an the override of: iguanair source: configure-generated-file-in-source config.status I believe that the override is justified since the upstream tarball doesn't include a configure.in source and cannot be remade with auto-tools. The upload would fix these bugs: 529955 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/iguanair - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/iguanair/iguanair_0.99-1.dsc I would be glad if someone reviewd anduploaded this package for me. Kind regards Stefanos Harhalakis -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Swig and Java bindings packaging
2009/5/22 Felipe Sateler : > Dmitrijs Ledkovs wrote: > >> I'm maintaining a C++ library. They have SWIG (python) and Java (dunno >> how) bindings which are not packaged right now. >> >> I would greatly appreciate if someone can point out good examples of >> packaged python-swig and / or Java bindings for libraries? >> >> I'm a bit stuck cause the bindings are not integrated into autofoo >> build system (it's not just additional flag to configure) and i >> struggling to get my head around how to link against a library which >> has just been build and not yet installed. >> > > SWIG is an interface generator for C++ into several languages. So probably > both interfaces in your program are SWIG-based. > > If the interfaces are not hooked into the package build system, then you > will probably have to invoke swig directly to generate them. My package > csound uses SWIG to generate Java, Python and Lua bindings. It uses scons, > however. > What package is this? > > -- > Felipe Sateler > It's libsword7 (currently only in experimental) Or newer upstream release bzr branch lp:~pkgcrosswire/libsword/main dget https://edge.launchpad.net/~pkgcrosswire/+archive/ppa/+files/sword_1.6.0-1~31~09.10.dsc -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
CMake: drop linking dependencies from KDE standard targets (was: Re: RFS: kde-plasmoid-yawp)
Dear mentors, in addition to the information you've found in the RFS I sent yesterday and which was available from the BTS (#529815), I'd like to point out, that the package is now managed in a SVN and the latest (development) version can be obtained from [0]. Now I have a question about CMake and how to best drop a few dependencies from standard targets provided by FindKDE4.cmake (and its included sub-scripts). dpkg-shlibdeps noticed unneeded linking against four libraries. They are all part of some standard linking target like kdecore. My current solution is to add »-Wl,--as-needed« to target_link_libraries(). I didn't try to manually string-replace the unneeded libraries from the variables for fear that might not work reliably on a possible future binNMU if the content of the variables/targets should have changed. But »-Wl,--as-needed« is not an optimal solution either, at least that's how I understand it from some blog entries on planet.debian.org in the past. So my question is: is there any clean way to get rid of such unneeded dependencies? Thank you in advance for checking the package and answering this question. Kind regards, Kai [0] svn://svn.carbon-project.org/deb-pkg/kde-plasmoid-yawp/trunk -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: deb...@carbon-project.org Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex) signature.asc Description: OpenPGP digital signature