RFS: libitpp (updated package)
Dear Mentors, I am looking for a sponsor for the new version 3.99.2-1 of my package libitpp. It builds these binary packages: libitpp-dev - C++ library for signal processing and communication libitpp6 - C++ library for signal processing and communication The package is lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libitpp - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_3.99.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Kumar Appaiah -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: ITR: libitpp (updated package)
On Sun, 1 Jul 2007 13:51:33 +0530 Kumar Appaiah [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 3.99.2-1 of my package libitpp. http://packages.qa.debian.org/libi/libitpp.html When asking for a sponsor, please mention whether the package already exists in Debian - i.e. whether you have had a sponsor who is now busy etc. Different sponsors have different requirements. The following are mine. ;-) It builds these binary packages: libitpp-dev - C++ library for signal processing and communication libitpp6 - C++ library for signal processing and communication (I wish the mentors template would require the long description in RFS emails.) A -dbg package needs to be provided. (-dbg packages are likely to become mandatory by Lenny.) There is 500kb of source in the doc/ directory and probably more by the time the generated HTML docs are installed - more than enough to warrant a -doc package too. With these in place, you can tweak the short descriptions to indicate what is contained in each package by only mentioning C++ library for libitpp6 and adding a suffix of (development files) (debug files) (documentation) or something along those lines. Compare with libqof1: ii libqof-backend-qsf0Query Object Framework - XML backend module ii libqof-backend-sqlite0 Query Object Framework - SQLite backend module ii libqof-dev Query Object Framework - Development Headers ii libqof-doc Query Object Framework - API Documentation ii libqof1Query Object Framework ii libqof1-dbgQuery Object Framework - Debug Symbols Some of the content from the Features list at http://itpp.sourceforge.net/ needs to be summarised in the long description - remove the repeated research section: It is being developed by researchers in these areas and is widely used by researchers, doesn't make a lot of sense and is probably redundant anyway. Explain what the package does, not who you expect to be able to use it. Shorten the bit about NEWCOM - mention NEWCOM if you have to, otherwise concentrate on what the library can do, not who might be using it outside Debian. These are trivial to fix: dpkg-source: warning: file debian/copyright has no final newline (either original or modified version) dpkg-source: warning: file debian/itpp-config.1 has no final newline (either original or modified version) dpkg-source: warning: file debian/changelog has no final newline (either original or modified version) dpkg-source: warning: file debian/libitpp6.docs has no final newline (either original or modified version) dpkg-source: warning: file debian/watch has no final newline (either original or modified version) dpkg-source: warning: file debian/control has no final newline (either original or modified version) dpkg-source: warning: file debian/libitpp-dev.manpages has no final newline (either original or modified version) Now to the serious stuff: What's the dependency on gcc-3.4 gcc-3.4-base all about? (brought in when built in pbuilder). Is atlas3 really dependent on such an old compiler? atlas doesn't seem to have had much attention upstream for some time. By depending on what appears to be a dead (or extremely slow) upstream, you may be storing up a lot of problems for your own package. Atlas3 already has an RC bug, filed by one of the gcc maintainers, regarding compiler issues. Is there an alternative? Is there anyone working on atlas upstream? The problem arises from the fortran dependency within atlas, it should be updated to use libfortran2 instead of libg2c0 but that is probably a large upstream change. Is it likely to happen? (It has also FTBFS on arm which is another RC bug.) http://buildd.debian.org/build.php?pkg=atlas3ver=3.6.0-20.6arch=arm 2 RC bugs, a dependency on an outdated compiler and a quiet/dead upstream have been more than enough to have even a popular package removed from a release before now - if that happens to atlas, your package will be removed too (especially as libitpp2 only has 6 popcon users). This package has a large dependency tree (127MB of archives). Libraries are difficult enough without adding so many dependencies. Tell me about yourself - how familiar are you with some of the dependencies of this package? I am interested in this package, even though it is clearly outside my normal remit of embedded development, but I am also concerned about whether it is wise to encourage a package with such problematic dependencies. The package is lintian clean. No, it is not. W: libitpp source: debian-rules-ignores-make-clean-error line 35 W: libitpp source: substvar-source-version-is-deprecated libitpp-dev I would be glad if someone uploaded this package for me. Sorry, not in the current state. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsij5T8Rl4n.pgp Description: PGP
Re: ITR: libitpp (updated package)
Neil Williams codehelp at debian.org writes: I am looking for a sponsor for the new version 3.99.2-1 of my package libitpp. http://packages.qa.debian.org/libi/libitpp.html When asking for a sponsor, please mention whether the package already exists in Debian - i.e. whether you have had a sponsor who is now busy etc. OK, so this is the last time I rely on the template in Mentors. Anyway, I thought the updated subject line would do, but it's OK. My mentor, Daniel Baumann, has decided to stop sponsoring packages. Therefore, I need someone else to help me out. It builds these binary packages: libitpp-dev - C++ library for signal processing and communication libitpp6 - C++ library for signal processing and communication (I wish the mentors template would require the long description in RFS emails.) A -dbg package needs to be provided. (-dbg packages are likely to become mandatory by Lenny.) Will look into this. There is 500kb of source in the doc/ directory and probably more by the time the generated HTML docs are installed - more than enough to warrant a -doc package too. Ah, so here's the trouble. I did _exactly_ that, but my previous sponsor told me not to do it, since he felt 500 kb didn't warrant a new package, and that the dev package is almost useless without the docs. But if you insist, so be it. With these in place, you can tweak the short descriptions to indicate what is contained in each package by only mentioning C++ library for libitpp6 and adding a suffix of (development files) (debug files) (documentation) or something along those lines. Compare with libqof1: I would request you to elaborate on this. Do you just mean to explain separation of packages into docs, dev and dbg? Some of the content from the Features list at http://itpp.sourceforge.net/ needs to be summarised in the long description - remove the repeated research section: [snip] Will be done. Shorten the bit about NEWCOM - mention NEWCOM if you have to, otherwise concentrate on what the library can do, not who might be using it outside Debian. Accepted. These are trivial to fix: dpkg-source: warning: file debian/copyright has no final newline (either original or modified version) dpkg-source: warning: file debian/itpp-config.1 has no final newline (either original or modified version) dpkg-source: warning: file debian/changelog has no final newline (either original or modified version) dpkg-source: warning: file debian/libitpp6.docs has no final newline (either original or modified version) dpkg-source: warning: file debian/watch has no final newline (either original or modified version) dpkg-source: warning: file debian/control has no final newline (either original or modified version) dpkg-source: warning: file debian/libitpp-dev.manpages has no final newline (either original or modified version) Fine. Now to the serious stuff: [snip] 2 RC bugs, a dependency on an outdated compiler and a quiet/dead upstream have been more than enough to have even a popular package removed from a release before now - if that happens to atlas, your package will be removed too (especially as libitpp2 only has 6 popcon users). This package has a large dependency tree (127MB of archives). Libraries are difficult enough without adding so many dependencies. I was unaware of the fact that atlas suffered from so many deficiencies. However, I guess I can drop dependency on atlas (see http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult upstream before doing that. Tell me about yourself - how familiar are you with some of the dependencies of this package? I am an end-user of this package, and not very familiar with the dependencies. Therefore, I didn't see the storm brewing. I am interested in this package, even though it is clearly outside my normal remit of embedded development, but I am also concerned about whether it is wise to encourage a package with such problematic dependencies. Well, I'll see what I can do. This will mean redoing a lot of old work, and will take some time. I guess I'll do this sometime in the next few days. The package is lintian clean. No, it is not. W: libitpp source: debian-rules-ignores-make-clean-error line 35 W: libitpp source: substvar-source-version-is-deprecated libitpp-dev Got that. I would be glad if someone uploaded this package for me. Sorry, not in the current state. I'll get back to you with a better package. Thanks for the inputs. Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ampache Sponsor
From: Charlie Smotherman [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: ampache Dear mentors, I am looking for a sponsor for my package ampache. * Package name: ampache Version : 3.3.3.2-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : web It builds these binary packages: ampache- A web based audio file management system written in PHP The package is lintian clean. The upload would fix these bugs: 407337 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ampache - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.3.3.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ampache sponsor
Ok let's try this one more time From: Charlie Smotherman [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: ampache Dear mentors, I am looking for a sponsor for my package ampache. * Package name: ampache Version : 3.3.3.2-1 Upstream Author : [EMAIL PROTECTED] * URL : www.ampache.org * License : GPL Section : web It builds these binary packages: ampache- A web based audio file management system written in PHP The package is lintian clean. The upload would fix these bugs: 407337 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ampache - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ampache/ampache_3.3.3.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sbuild and -vversion dpkg-buildpackage option
Hello, I used to create one package with using the -vversion dpkg-buildpackage option. Now my sponsor uses sbuild. How can the -vversion option be passed to sbuild? I personally don't use sbuild, but took a quick look into the manpage, but didn't find anything. Or are there any workarounds? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: powertop (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.7~svn-r227-1 of my package powertop. It builds these binary packages: powertop - linux tool to find out what is using power on a laptop The package is lintian clean. The upload would fix these bugs: 427345, 427548, 429305, 430035 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/powertop - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/powertop/powertop_1.7~svn-r227-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: powertop (updated package)
On Sun, Jul 01, 2007 at 05:21:03PM +0200, Krzysztof Burghardt wrote: I am looking for a sponsor for the new version 1.7~svn-r227-1 of my package powertop. Sponsored! Is there a reason you took the SVN version instead of 1.7 stable? Funny though that uscan found out there is a 1.17 version online although the web site says 1.7 is the most current version. Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. signature.asc Description: Digital signature
RFS: secpanel (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.41+0.4.2-4 of my package secpanel. It builds these binary packages: secpanel - A graphical user interface for SSH and SCP The upload would fix these bugs: 317063 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/secpanel - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/secpanel/secpanel_0.41+0.4.2-4.dsc I would be glad if someone uploaded this package for me. Kind regards Bruno Costacurta -- PGP key ID: 0x2e604d51 Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- pgpLSpSJBz88p.pgp Description: PGP signature
Re: ITS: fortunes-ru -- Russian data files for fortune
Hi, * Denis V. Sirotkin [EMAIL PROTECTED] [2007-07-01 16:25]: I am looking for a sponsor for my package fortunes-ru. I will sponsor this package. Just a few notes: You use the Homepage tag in control but you just indent with· one space, please use 2 as described in 6.2.4 developers· reference. You use Architecture: any in control which is wrong since· the fortune data is architecture-independent. Please fix· this, see policy 5.6.8. Why do you have a build-dependency on fortune-mod? The package is lintian clean. It's not please check. Fix the above issues and I will upload the package for you. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpbiReTCvo2R.pgp Description: PGP signature
A note on lintian clean packages and mentors.d.n
Hi, I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: Please check your package for the Debian policy using the lintian package. If it doesn't complain please state that the package is lintian clean. This is a must for most of the packages. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpQTxPXXInxu.pgp Description: PGP signature
Re: RFS: secpanel (updated package)
Hi Bruno, On Sunday 1 July 2007 18:01, Bruno Costacurta wrote: Dear mentors, I am looking for a sponsor for the new version 0.41+0.4.2-4 of my package secpanel. Thanks for your effort to adopt an orphaned package. I've taken a look and have the following points: - Why the strange version number 0.41+0.4.2? - You've made two changes like this: -#!/bin/sh +#!/usr/bin/wish but do not document that in the changelog. - You seemed to have switched the package from non-native to Debian native, perhaps an accident? If you use debuild to build your package you will be warned of that. Otherwise it looks fine. Thijs pgpXdbdc0WTPP.pgp Description: PGP signature
Re: RFS: secpanel (updated package)
On Sunday 1 July 2007 18:12, Thijs Kinkhorst wrote: Otherwise it looks fine. One more thing: there's some bugs open against the package, including a wishlist bug regarding a new upstream version. Perhaps you want to take a look at those to see whether you can address them? Thijs pgpI0XF2rc02N.pgp Description: PGP signature
Re: ampache sponsor
Hi Charlie, On Sunday 1 July 2007 12:43, Charlie wrote: Dear mentors, I am looking for a sponsor for my package ampache. I've taken a look and have found the following remarks. * You install under /usr/share/ampache. The webapps policy (still draft, but not quite controversial) recommends /usr/share/ampache/www. I suggest to change it because changing it later can be bothersome. * Your debconf template reads: Ampache supports any web server that php and mysql does, but this automatic configuration process only supports Apache2. Please select which apache version you want to configure. It only supports Apache2 but you can indicate which version to configure? That doesn't make sense. You also sometimes write Apache and sometimes apache. * You depend on php5-common, is that really necessary or already satisfied by the other dependencies? * You depend on dbconfig-common but don't use it. * debian/copyright reads: This package was debianized by root [EMAIL PROTECTED]. * In debian/rules you do some loops to install your files. Can't you use the dh_install call to handle this for you? Otherwise it generally looks quite ok, thanks for your work! Thijs pgprCCp7T2dD4.pgp Description: PGP signature
Re: A note on lintian clean packages and mentors.d.n
On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote: I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: Please check your package for the Debian policy using the lintian package. If it doesn't complain please state that the package is lintian clean. This is a must for most of the packages. Sounds a bit complicated. I have changed the text slightly to ...appears to be lintian-clean. The lintian version on mentors.debian.net is the Etch version. We can install a backport though. Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. signature.asc Description: Digital signature
Re: A note on lintian clean packages and mentors.d.n
Hi, * Christoph Haas [EMAIL PROTECTED] [2007-07-01 19:13]: On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote: I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: [...] Sounds a bit complicated. I have changed the text slightly to ...appears to be lintian-clean. The lintian version on mentors.debian.net is the Etch version. We can install a backport though. That would be very nice. Thanks Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpEqF4INUK6z.pgp Description: PGP signature
Re: RFS: secpanel (updated package)
On Sunday 01 July 2007 18:12, Thijs Kinkhorst wrote: Hi Bruno, On Sunday 1 July 2007 18:01, Bruno Costacurta wrote: Dear mentors, I am looking for a sponsor for the new version 0.41+0.4.2-4 of my package secpanel. Thanks for your effort to adopt an orphaned package. I meet few Debian guys and they reckon this is the best way to start giving collaboration (modest as a newbie) to Debian. I've taken a look and have the following points: - Why the strange version number 0.41+0.4.2? Indeed. I was ot sure about which numbering I should adopt and try to follow current one as a first upload. - You've made two changes like this: -#!/bin/sh +#!/usr/bin/wish but do not document that in the changelog. Right. Changelog to be completed. - You seemed to have switched the package from non-native to Debian native, perhaps an accident? If you use debuild to build your package you will be warned of that. I used dpkg-buildpackage. I did not notice this switch. Should I use 'debuild' and leave dpkg-buildpackage ? Otherwise it looks fine. Question: can I submit (still via mentors-debian) a new version called 0.42 including these corrections / remarks ? Thijs Thanks for your attention. Bye, Bruno -- PGP key ID: 0x2e604d51 Key : http://www.costacurta.org/keys/bruno_costacurta_pgp_key.html Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 --
Re: RFS: powertop (updated package)
On Sun, 1 Jul 2007 17:57:50 +0200 Christoph Haas [EMAIL PROTECTED] wrote: Funny though that uscan found out there is a 1.17 version online although the web site says 1.7 is the most current version. When I browse to: http://www.linuxpowertop.org/download/ there actually is a version 1.17. Looks like a problem on Arjan's side. -- bye ranf signature.asc Description: PGP signature
Re: RFS: secpanel (updated package)
On Sun, 1 Jul 2007 18:01:39 +0200 Bruno Costacurta [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 0.41+0.4.2-4 of my package secpanel. Small typo in debian/control: managining -- bye ranf signature.asc Description: PGP signature
Re: RFS: gimmie
Thierry Randrianiriana schrieb: Dear mentors, I am looking for a sponsor for my package gimmie. * Package name: gimmie Version : 0.2.7-1 Upstream Authors: Alex Graveley [EMAIL PROTECTED] David Trowbridge [EMAIL PROTECTED] Mike Hearn [EMAIL PROTECTED] Tony Tsui [EMAIL PROTECTED] * URL : http://www.beatniksoftware.com/gimmie * License : LGPL Section : gnome It builds these binary packages: gimmie - elegant desktop organizer The package is lintian clean. The upload would fix these bugs: 415937 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gimmie - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gimmie/gimmie_0.2.7-1.dsc I would be glad if someone uploaded this package for me. Hi Thierry, the package looks well done, I only have some smaller points: 1.) Package description gimmie seems to be a replacement/enhancement of the traditional (GNOME) panel and it can either be run in standalone mode or as applet in the GNOME panel. This information is somehow missing in the description. 2.) The second paragraph in the long descriptions does not show nicely in aptitude. The separate points are not correctly wrapped and thus it gets a bit unreadable. 3.) python-support IIRC the recommended way to specify the supported python versions with python-support is debian/pyversions [1]. But as python-support also supports the XS-Python-Version field, you can also keep it as is. 4.) ./configure checks for a couple of python modules like gmenu etc, which are are not added to the the Depends list of gimmie. Could you elaborate on that? Should these python modules be added to the list of runtime dependencies? 5.) debian/copyright gdm-logout-action.c is missing 6.) inlined copy of libsexy gimmie uses a inlined copy of libsexy. I would very much prefer if gimmie could be made to use the system libsexy. See [2] for more details. Maybe you can also forward this information to upstream. If you can address the above issues, I'll gladly sponsor your package. Cheers, Michael [1] http://wiki.debian.org/DebianPython/NewPolicy [2] http://www.chipx86.com/blog/?p=205 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: ITR: libitpp (updated package)
On Sun, 1 Jul 2007 09:58:52 + (UTC) Kumar Appaiah [EMAIL PROTECTED] wrote: Neil Williams codehelp at debian.org writes: I am looking for a sponsor for the new version 3.99.2-1 of my package libitpp. When asking for a sponsor, please mention whether the package already exists in Debian - i.e. whether you have had a sponsor who is now busy etc. OK, so this is the last time I rely on the template in Mentors. Anyway, I thought the updated subject line would do, but it's OK. That's the thing with templates - they are meant to be edited. ;-) Do please use the template, just ensure that you add sufficient information to the template for your specific request and check that every single part of the template is accurate *before* clicking Send. A -dbg package needs to be provided. (-dbg packages are likely to become mandatory by Lenny.) Will look into this. It should be a simple addition to dh_strip: dh_strip --dbg-package=libfooSONAME-dbg and then the content in debian/control -dbg packages should usually be priority extra if the package is optional or optional|extra for higher priorities. There is 500kb of source in the doc/ directory and probably more by the time the generated HTML docs are installed - more than enough to warrant a -doc package too. Ah, so here's the trouble. I did _exactly_ that, but my previous sponsor told me not to do it, since he felt 500 kb didn't warrant a new package, and that the dev package is almost useless without the docs. But if you insist, so be it. In practical terms, not all those who need the -dev package are actually writing new software with that -dev. A lot are simply *building* reverse dependencies of that -dev. When someone needs to build pilot-qof, there is no need for them to have libqof-doc, they only need libqof-dev. Such issues also affect the autobuilders - there is no need for them to have the doc content when trying to build a dependency using the -dev. With these in place, you can tweak the short descriptions to indicate what is contained in each package by only mentioning C++ library for libitpp6 and adding a suffix of (development files) (debug files) (documentation) or something along those lines. Compare with libqof1: I would request you to elaborate on this. Do you just mean to explain separation of packages into docs, dev and dbg? No, tidying up the short descriptions so that the new packages are not simple copies (as the -dev is currently). libqof-dev Query Object Framework - Development Headers libqof-doc Query Object Framework - API Documentation libqof1 Query Object Framework libitpp-dev - signal processing and communication - development files libitpp-doc - signal processing and communication - API documentation libittp-dbg - signal processing and communication - debug symbols libitpp6- C++ library for signal processing and communication debtags are useful too but a lot of people still limit their searches to apt-cache search so it is best to make short descriptions unique. This package has a large dependency tree (127MB of archives). Libraries are difficult enough without adding so many dependencies. I was unaware of the fact that atlas suffered from so many deficiencies. ? You should always build your own packages with pbuilder at least once for each upstream release - if only to ensure you have the Build-Depends right. Simply watching or reading the pdebuild log will show you that your package brings in more packages than a relatively large GUI application. Please look beyond your own package and try to anticipate problems. However, I guess I can drop dependency on atlas (see http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult upstream before doing that. Yes, the reduced functionality is a concern. Upstream may be able to separate the codebase so that you can create a libitpp-atlas6 and libittp6 that would be without atlas - one conflicting and replacing the other (not ideal) or one complementing the other by adding new files without replacing libittp6 (harder to do upstream). It's not something to do now (unless upstream already make it easy to do) but ensure that you subscribe to atlas via the PTS so that you are kept updated with the status of it's RC bug(s) and general health. Just put your email address into the subscribe box at: http://packages.qa.debian.org/a/atlas3.html Note that according to the PTS, the maintainer of atlas has not made an upload himself since 2005, there are 4 unapplied patches in the BTS (two of which are debconf translations that are normally trivial to apply) and the standards version is out of date. All signs of a maintainer who is more active in other areas as well as a quiet/dead upstream. Tell me about yourself - how familiar are you with some of the dependencies of this package? I am an end-user of this package, and not very familiar with the dependencies. Therefore, I didn't see the
Re: RFS: powertop (updated package)
2007/7/1, Christoph Haas [EMAIL PROTECTED]: Sponsored! Is there a reason you took the SVN version instead of 1.7 stable? Just because it have been translated to Polish (in opposite to pure 1.7). Thanks for upload. Regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A note on lintian clean packages and mentors.d.n
On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote: Hi, * Christoph Haas [EMAIL PROTECTED] [2007-07-01 19:13]: On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote: I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: [...] Sounds a bit complicated. I have changed the text slightly to ...appears to be lintian-clean. The lintian version on mentors.debian.net is the Etch version. We can install a backport though. That would be very nice. Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps. Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. signature.asc Description: Digital signature
Request for additions to the mentors RFS template
I'd like to ask if the template could advise/require that certain extra fields are always specified? 1. An ITP usually includes a Language: C/C++/Python/Perl etc. line, so for requests for sponsors, it would be good to carry this over so that packages that already exist in the archive also carry this information in the RFS. It would help me enormously to be able to scan the RFS and disregard all python or ruby packages and concentrate on C/C++ or Perl without having to research each one via various web pages. 2. I frequently find that the short description of RFS emails is insufficient and I would value the opportunity to scan RFS emails that include the long description. Descriptions are commonly tweaked during the process of sponsorship as it is rare that a new maintainer makes a genuinely understandable short and long description on their first attempt and existing packages can also suffer from poor descriptions. 3. The URL field is commonly just the URL for the mentors.debian.net site (which itself is often little more than the template) when it would be useful to either recommend the upstream homepage or include that separately - naturally, if the long description is included, a lot of packages will include this anyway. (Those that do not include a Homepage link in the long description should expect to be asked to add one.) 4. Some kind of statement in the template that a bare template with minimal information is usually insufficient. Those who may want to ask me to sponsor their packages, please note - if you include this information in the very first RFS email to this list, you have a much higher chance of attracting my interest. In most cases, a bare template RFS will simply be ignored, regardless of the merits of that particular package. Personally, I expect people requesting sponsorship to be enthusiastic about the package to be sponsored. I would expect such enthusiasm to manifest as a tendency to include too much information rather than too little and I am prone to disregarding requests for sponsorship that suffer from a lack of information in the original RFS. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpK1klgdY1gh.pgp Description: PGP signature
Re: RFS: ntfs-config
On Thu, Jun 28, 2007 at 08:37:33PM +, Joseph Nahmias wrote: Can you please give more information about what ntfs-config actually does. Also, the URL above does not respond... Here is where the first RFS thread started: http://lists.debian.org/debian-mentors/2007/06/msg00055.html Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for additions to the mentors RFS template
Hi, * Neil Williams [EMAIL PROTECTED] [2007-07-01 20:29]: I'd like to ask if the template could advise/require that certain extra fields are always specified? 1. An ITP usually includes a Language: C/C++/Python/Perl etc. line, so for requests for sponsors, it would be good to carry this over so that packages that already exist in the archive also carry this information in the RFS. It would help me enormously to be able to scan the RFS and disregard all python or ruby packages and concentrate on C/C++ or Perl without having to research each one via various web pages. Is this really necessary as the information should be present in the ITP? 2. I frequently find that the short description of RFS emails is insufficient and I would value the opportunity to scan RFS emails that include the long description. Descriptions are commonly tweaked during the process of sponsorship as it is rare that a new maintainer makes a genuinely understandable short and long description on their first attempt and existing packages can also suffer from poor descriptions. ACK and iirc it was common practice to include the long description in RFS requests back in the days before mentors.d.n :) 3. The URL field is commonly just the URL for the mentors.debian.net site (which itself is often little more than the template) when it would be useful to either recommend the upstream homepage or include that separately - naturally, if the long description is included, a lot of packages will include this anyway. (Those that do not include a Homepage link in the long description should expect to be asked to add one.) As the upstream homepage should be also in the ITP for my taste the URL is just obsolete if a dget URL is included. 4. Some kind of statement in the template that a bare template with minimal information is usually insufficient. Those who may want to ask me to sponsor their packages, please note - if you include this information in the very first RFS email to this list, you have a much higher chance of attracting my interest. In most cases, a bare template RFS will simply be ignored, regardless of the merits of that particular package. ACK. I want to come up with an additional wish. 5. If the RFS is for a package update, please include a debdiff between the versions. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpZpOBcgQU5t.pgp Description: PGP signature
Re: A note on lintian clean packages and mentors.d.n
On 01/07/07, Christoph Haas [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote: Hi, * Christoph Haas [EMAIL PROTECTED] [2007-07-01 19:13]: On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote: I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: [...] Sounds a bit complicated. I have changed the text slightly to ...appears to be lintian-clean. The lintian version on mentors.debian.net is the Etch version. We can install a backport though. That would be very nice. Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps. Is lintian only checking the .deb file or the .dsc file too? By the way, what do you think about making linda check the package too? Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGh+6eCV53xXnMZYYRArtLAJ9SEollItFIN3eKdpWLJH+ezLxgJwCfbrlD rYYTgcV2OzFlRzL+FdRtiVQ= =PGV7 -END PGP SIGNATURE- -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A note on lintian clean packages and mentors.d.n
Hi, * Raphael Geissert [EMAIL PROTECTED] [2007-07-01 21:41]: On 01/07/07, Christoph Haas [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote: [...] Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps. Is lintian only checking the .deb file or the .dsc file too? Not that I know it but I guess the scan the .changes file. By the way, what do you think about making linda check the package too? Linda itself is too buggy I think. Linda is not bad but when looking at the past I came to a point where I stopped using it because of its bugs. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp8SJQsPy88q.pgp Description: PGP signature
Re: A note on lintian clean packages and mentors.d.n
Hi, On 01/07/07, Nico Golde [EMAIL PROTECTED] wrote: Hi, * Raphael Geissert [EMAIL PROTECTED] [2007-07-01 21:41]: On 01/07/07, Christoph Haas [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote: [...] Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps. Is lintian only checking the .deb file or the .dsc file too? Not that I know it but I guess the scan the .changes file. By the way, what do you think about making linda check the package too? Linda itself is too buggy I think. Linda is not bad but when looking at the past I came to a point where I stopped using it because of its bugs. I have an alias in my .bashrc which helps me with this stuff: alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I *.deb; lintian -i -I *.dsc' The only problem I've found with linda is that when checking the source of a package it sometimes complains about duplicate files like: W: zend-framework; The font zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in package ttf-bitstream-vera is considered to be a duplicate. The font shown above is considered to be a duplicate of a commonly available font. even tough those files aren't included in the final .deb Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A note on lintian clean packages and mentors.d.n
Hi, * Raphael Geissert [EMAIL PROTECTED] [2007-07-01 21:51]: [...] By the way, what do you think about making linda check the package too? Linda itself is too buggy I think. Linda is not bad but when looking at the past I came to a point where I stopped using it because of its bugs. I have an alias in my .bashrc which helps me with this stuff: alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I *.deb; lintian -i -I *.dsc' The only problem I've found with linda is that when checking the source of a package it sometimes complains about duplicate files like: W: zend-framework; The font zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in package ttf-bitstream-vera is considered to be a duplicate. The font shown above is considered to be a duplicate of a commonly available font. even tough those files aren't included in the final .deb Linda has way too much false-positives (the above is just one example) which is really bad. bugs.debian.org/linda vs bugs.debian.org/lintian does look like this as well. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpNi4Dn99Ll8.pgp Description: PGP signature
Re: Request for additions to the mentors RFS template
On Sun, 1 Jul 2007 20:54:35 +0200 Nico Golde [EMAIL PROTECTED] wrote: 1. An ITP usually includes a Language: C/C++/Python/Perl etc. line, so for requests for sponsors, it would be good to carry this over so that packages that already exist in the archive also carry this information in the RFS. It would help me enormously to be able to scan the RFS and disregard all python or ruby packages and concentrate on C/C++ or Perl without having to research each one via various web pages. Is this really necessary as the information should be present in the ITP? I'm thinking of requests that don't involve an ITP, as above, where the package already exists in the archive. It would still be useful to have it, from my perspective, in the RFS without having to load up the web browser to inspect the ITP. 3. The URL field is commonly just the URL for the mentors.debian.net site (which itself is often little more than the template) when it would be useful to either recommend the upstream homepage or include that separately - naturally, if the long description is included, a lot of packages will include this anyway. (Those that do not include a Homepage link in the long description should expect to be asked to add one.) As the upstream homepage should be also in the ITP for my taste the URL is just obsolete if a dget URL is included. As above, if there is no ITP, this gets left behind. However, this is a minor request. 5. If the RFS is for a package update, please include a debdiff between the versions. That's a great idea! mentors.debian.net may even be able to do that automatically and put the results in the same directory as the .dsc - perhaps running either debdiff or interdiff against the existing version in the debian archive. 'interdiff -z ' against the two .diff.gz files would be useful. It doesn't help native packages but then that's probably for the best, an RFS doesn't usually intend to relate to a native package. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpbYl2V1KSkc.pgp Description: PGP signature
Re: A note on lintian clean packages and mentors.d.n
Hi, On 01/07/07, Nico Golde [EMAIL PROTECTED] wrote: Hi, * Raphael Geissert [EMAIL PROTECTED] [2007-07-01 21:51]: [...] By the way, what do you think about making linda check the package too? Linda itself is too buggy I think. Linda is not bad but when looking at the past I came to a point where I stopped using it because of its bugs. I have an alias in my .bashrc which helps me with this stuff: alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I *.deb; lintian -i -I *.dsc' The only problem I've found with linda is that when checking the source of a package it sometimes complains about duplicate files like: W: zend-framework; The font zend-framework-1.0.0-RC2/tests/Zend/Pdf/_fonts/Vera.ttf in package ttf-bitstream-vera is considered to be a duplicate. The font shown above is considered to be a duplicate of a commonly available font. even tough those files aren't included in the final .deb Linda has way too much false-positives (the above is just one example) which is really bad. bugs.debian.org/linda vs bugs.debian.org/lintian does look like this as well. There are only 5 bugs in linda: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=srcdata=lindaarchive=nopend-exc=pending-fixedpend-exc=fixedpend-exc=donesev-inc=importantsev-inc=normal By the way, looks like the BTS is kind of buggy: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=srcdata=lindaarchive=norepeatmerged=noversion=dist=unstablepend-exc=pending-fixedpend-exc=fixedpend-exc=donesev-exc=wishlistsev-exc=fixedexclude=fixedexclude=fixed-in-experimentalexclude=fixed-upstream That should normally exclude all those bugs marked as done, but it isn't excluding them. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: command-not-found
Dear mentors, I am looking for a sponsor for my package command-not-found. * Package name: command-not-found Version : 0.2.4+debian-1 Upstream Author : Zygmunt Krynicki [EMAIL PROTECTED] Michael Vogt [EMAIL PROTECTED] * URL : https://launchpad.net/command-not-found * License : GPL Section : admin It builds these binary packages: command-not-found - Suggest installation of packages in interactive bash sessions command-not-found-data - Set of data files for command-not-found The package appears to be lintian clean. The upload would fix these bugs: 418613 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/command-not-found - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/command-not-found/command-not-found_0.2.4+debian-1.dsc I would be glad if someone uploaded this package for me. Kind regards Julian Andres Klode -- Julian Andres Klode IRC Nickname: juliank (Debian/OFTC + Freenode) Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049) Debian Wiki:http://wiki.debian.org/JulianAndresKlode Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode In Launchpad: https://launchpad.net/~juliank Packages Overv: http://qa.debian.org/[EMAIL PROTECTED] Languages: German, English, [bit French] signature.asc Description: OpenPGP digital signature
Re: A note on lintian clean packages and mentors.d.n
On Sun, Jul 01, 2007 at 02:39:10PM -0500, Raphael Geissert wrote: On 01/07/07, Christoph Haas [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2007 at 07:21:51PM +0200, Nico Golde wrote: Hi, * Christoph Haas [EMAIL PROTECTED] [2007-07-01 19:13]: On Sun, Jul 01, 2007 at 06:11:00PM +0200, Nico Golde wrote: I saw many packages using the template from mentors.debian.net which then always says: The package is lintian clean. And I saw many packages which are not lintian clean but state otherwise which really sucks. Can you change this string to something like: [...] Sounds a bit complicated. I have changed the text slightly to ...appears to be lintian-clean. The lintian version on mentors.debian.net is the Etch version. We can install a backport though. That would be very nice. Lintian is now v1.23.31 instead of v1.23.28 (Etch). Hope that helps. Is lintian only checking the .deb file or the .dsc file too? By the way, what do you think about making linda check the package too? The .deb file (if it is uploaded at all) is thrown away. Lintian is doing the checks on the .dsc file. /me puts linda on the todo list. Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: command-not-found
On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote: Dear mentors, I am looking for a sponsor for my package command-not-found. * Package name: command-not-found Version : 0.2.4+debian-1 Upstream Author : Zygmunt Krynicki [EMAIL PROTECTED] Michael Vogt [EMAIL PROTECTED] * URL : https://launchpad.net/command-not-found * License : GPL Section : admin Not sure. Perhaps shell as a section might match better. It builds these binary packages: command-not-found - Suggest installation of packages in interactive bash sessions command-not-found-data - Set of data files for command-not-found I just built and installed it. There is some funny whitespace in between the messages: === $ inetd Command 'inetd' is available in '/usr/sbin/inetd' The command could not be located because '/usr/sbin' is not i ncluded in the PATH environment variable. This is most likely caused by the lack of administ rative priviledges associated with your user account. bash: inetd: command not found === i ncluded - included administ rative - administrative priviledges - privileges Did you talk to the Ubuntu maintainer already? Perhaps it make sense to join forces so that only one package is built? Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: app-install-data (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.20070627 of my package app-install-data (I took it over from the previous maintainer, with permission). It builds these binary packages: app-install-data - Application Installer Data Files The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/app-install-data - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/app-install-data/app-install-data_0.20070627.dsc I would be glad if someone uploaded this package for me. Kind regards Julian Andres Klode -- Julian Andres Klode IRC Nickname: juliank (Debian/OFTC + Freenode) Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049) Debian Wiki:http://wiki.debian.org/JulianAndresKlode Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode In Launchpad: https://launchpad.net/~juliank Packages Overv: http://qa.debian.org/[EMAIL PROTECTED] Languages: German, English, [bit French] signature.asc Description: OpenPGP digital signature
Re: RFS: command-not-found
Christoph Haas wrote: On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote: Dear mentors, I am looking for a sponsor for my package command-not-found. * Package name: command-not-found Version : 0.2.4+debian-1 Upstream Author : Zygmunt Krynicki [EMAIL PROTECTED] Michael Vogt [EMAIL PROTECTED] * URL : https://launchpad.net/command-not-found * License : GPL Section : admin Not sure. Perhaps shell as a section might match better. It builds these binary packages: command-not-found - Suggest installation of packages in interactive bash sessions command-not-found-data - Set of data files for command-not-found I just built and installed it. There is some funny whitespace in between the messages: === $ inetd Command 'inetd' is available in '/usr/sbin/inetd' The command could not be located because '/usr/sbin' is not i ncluded in the PATH environment variable. This is most likely caused by the lack of administ rative priviledges associated with your user account. bash: inetd: command not found === i ncluded - included administ rative - administrative priviledges - privileges Fixed. Did you talk to the Ubuntu maintainer already? Perhaps it make sense to join forces so that only one package is built? He's CCed, so: mvo: What's your opinion? -- Julian Andres Klode IRC Nickname: juliank (Debian/OFTC + Freenode) Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049) Debian Wiki:http://wiki.debian.org/JulianAndresKlode Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode In Launchpad: https://launchpad.net/~juliank Packages Overv: http://qa.debian.org/[EMAIL PROTECTED] Languages: German, English, [bit French] signature.asc Description: OpenPGP digital signature
RFS: syck
Dear mentors, I am looking for the new version 0.55+svn256-1 of the package syck which is already in Debian, maintained by Robert Jordens [EMAIL PROTECTED]. jordens doesn't use it any more and has given me permission to take it. (He isn't responding to my mail - might be on vacation) * Package name: syck Version : 0.55+svn256-1 Upstream Author : Why The Lucky Stiff [EMAIL PROTECTED] * URL : http://whytheluckystiff.net/syck * License : BSD Section : devel * Syck is a simple YAML parser kit. . YAML(tm) (rhymes with 'camel') is a straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, formatted dumping, configuration files, log files, Internet messaging and filtering. This specification describes the YAML information model and serialization format. Together with the Unicode standard for characters, it provides all the information necessary to understand YAML Version 1.0 and construct computer programs to process it. . The whole point of Syck is to make parsing and emitting YAML very simple for scripting languages through C bindings. It doesn't strive to be a pull parser or very extendible. It just is concerned with loading a YAML document into a C structure which can be easily translated into a scripting language's internal native data type. It builds these binary packages: libsyck0-dev - YAML parser kit -- development files php5-syck - YAML parser kit -- PHP5 bindings The package is lintian and linda clean The upload would fix these bugs: 324316, 359245, 378440, 415217, 418308 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/syck - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/syck/syck_0.55+svn256-1.dsc I would be very glad if someone uploaded this package for me. -- Regards, Thomas Jollans GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu Hacker key http://hackerkey.com/: v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6 signature.asc Description: This is a digitally signed message part.
Re: RFS: secpanel (updated package)
On Sunday 01 July 2007 18:15, Thijs Kinkhorst wrote: On Sunday 1 July 2007 18:12, Thijs Kinkhorst wrote: Otherwise it looks fine. One more thing: there's some bugs open against the package, including a wishlist bug regarding a new upstream version. Perhaps you want to take a look at those to see whether you can address them? Thijs I'll update with latest upstream and upload to debian-mentors. Bye, Bruno -- PGP key ID: 0x2e604d51 Key fingerprint = 713F 7956 9441 7DEF 58ED 1951 7E07 569B 2E60 4D51 -- pgprUn4WHtBCY.pgp Description: PGP signature
Re: A note on lintian clean packages and mentors.d.n
On Sun, 1 Jul 2007 15:05:54 -0500 Raphael Geissert [EMAIL PROTECTED] wrote: I have an alias in my .bashrc which helps me with this stuff: alias checkdeb='linda -i *.deb; linda -i *.dsc; lintian -i -I *.deb; lintian -i -I *.dsc' What's wrong with just passing the .changes? That checks the .dsc and each .deb I stopped using linda some time ago - it is just incredibly buggy. I admit I didn't file a bug report for every false positive or other linda problem. I just uninstalled linda. It shouldn't be too hard for someone to identify all packages in the archive that are lintian-clean (without overrides) and run them through linda to get a report of where lintian and linda disagree. Not all of those will be bugs (because linda works differently to lintian and can catch problems that lintian cannot and vice versa) but it's not something I would want to do. Linda has way too much false-positives (the above is just one example) which is really bad. bugs.debian.org/linda vs bugs.debian.org/lintian does look like this as well. There are only 5 bugs in linda: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=srcdata=lindaarchive=nopend-exc=pending-fixedpend-exc=fixedpend-exc=donesev-inc=importantsev-inc=normal Minor and wishlist bugs still count - particularly for things like linda and lintian, which leads to 16 outstanding. (The lintian maintainer correctly insists that lintian - and therefore linda - are only indicators of problems and cannot catch all such problems, they are not intended to be the authoritative implementation of Policy. Therefore, bugs in linda or lintian that relate to false positives, missing checks and wrong results are requested to be filed as wishlist only.) On that score, lintian has 99 bugs - yet lintian is still the better of the two. As indicators of problems, lintian is the one to use but you and I know that just because a package is lintian clean does NOT mean that the package is in a good enough condition to be uploaded. Equally, there are a small number of instances where a lintian override is the correct response to a lintian error but sponsorees should not use overrides without talking to their sponsor first! -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpmcAMKvDLjW.pgp Description: PGP signature
Re: RFS: command-not-found
On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote: Dear mentors, I am looking for a sponsor for my package command-not-found. * Package name: command-not-found Version : 0.2.4+debian-1 Upstream Author : Zygmunt Krynicki [EMAIL PROTECTED] Michael Vogt [EMAIL PROTECTED] * URL : https://launchpad.net/command-not-found * License : GPL Section : admin It builds these binary packages: command-not-found - Suggest installation of packages in interactive bash sessions How does it compare with auto-apt? This a shell-only implementation whereas auto-apt will find things which are accessed otherwise (perhaps not bad). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A note on lintian clean packages and mentors.d.n
Neil Williams [EMAIL PROTECTED] writes: Minor and wishlist bugs still count - particularly for things like linda and lintian, which leads to 16 outstanding. (The lintian maintainer correctly insists that lintian - and therefore linda - are only indicators of problems and cannot catch all such problems, they are not intended to be the authoritative implementation of Policy. Therefore, bugs in linda or lintian that relate to false positives, missing checks and wrong results are requested to be filed as wishlist only.) On that score, lintian has 99 bugs - yet lintian is still the better of the two. Minor correction: Missing checks should be filed as wishlist bugs, but false positives and wrong results, unless explicitly already noted in the long tag description, should be filed at normal or minor severity. I try to correct those as much as possible before each upload. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITS: fortunes-ru -- Russian data files for fortune
2007/7/1, Nico Golde [EMAIL PROTECTED]: Hi, * Denis V. Sirotkin [EMAIL PROTECTED] [2007-07-01 16:25]: I am looking for a sponsor for my package fortunes-ru. I will sponsor this package. Just a few notes: You use the Homepage tag in control but you just indent with· one space, please use 2 as described in 6.2.4 developers· reference. Done. You use Architecture: any in control which is wrong since· the fortune data is architecture-independent. Please fix· this, see policy 5.6.8. Done. Why do you have a build-dependency on fortune-mod? Oh! I had removed this. The package is lintian clean. It's not please check. Fix the above issues and I will upload the package for you. Fixed and uploaded to mentors.d.o. Please check again. Thanks in advance. -- wbr Denis Sirotkin
Re: RFS: kde-icons-crystalproject
On 6/28/07, Raphael Geissert [EMAIL PROTECTED] wrote: I'm using a datestamp because that seems to be the best way to handle the 'version' of the icons pack. To prevent the need for an epoch if upstream decides to use versions, you might want to go with something like 0.0.20070625-1 or 0.0.2007.06.25-1. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
