Re: RFS: swath 0.3.3-1 (updated package)
On Thu, Mar 20, 2008 at 9:30 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 0.3.3-1 of my package swath. Please fix this GCC warning, after that I will upload: /tmp/buildd/swath-0.3.3/src/wordseg.cpp:244: warning: the use of `tmpnam' is dangerous, better use `mkstemp' Have you considered applying for DM? http://wiki.debian.org/Maintainers -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: QTM - Qt4 blogging client
On Thu, Mar 20, 2008 at 08:08:42PM +0100, Patryk Cisek wrote: Package name: QTM Version: 0.5.8.2 Upstream author: M.J. Smith indigojo_uk AT yahoo DOT co DOT uk ^ Is address obfuscation really necessary? Google for address munging considered harmful -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swath 0.3.3-1 (updated package)
On Sat, 22 Mar 2008 15:37:38 +0900, Paul Wise [EMAIL PROTECTED] wrote: On Thu, Mar 20, 2008 at 9:30 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 0.3.3-1 of my package swath. Please fix this GCC warning, after that I will upload: /tmp/buildd/swath-0.3.3/src/wordseg.cpp:244: warning: the use of `tmpnam' is dangerous, better use `mkstemp' This may be better done by a new upstream release. In fact, using mkstemp() instead of tmpnam() means quite substantial change to the program logic, because the temp files are actually created deep in different functions in different branches, using the generated temp names from a single place. Changing that behavior would mean internal API changes. I will come up with a new upstream version soon, then. Have you considered applying for DM? http://wiki.debian.org/Maintainers Yes, I'll apply soon, but probably not before this upload. I would like to have the regression fixed sooner. BTW, do you think I should raise the urgency from low to medium, although it does not fix any RC bug in Debian BTS? The regression was reported upstream, not in Debian BTS, but it must have been a grave bug had it been filed. It's a total loss of functionality. Thanks, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ signature.asc Description: Digital signature
RFS: libemail-find-perl and libhtml-fromtext-perl bug fix update.
Hi DD, I'm looking a sponsor for update my perl packages: Package Name: libemail-find-perl Short description: Find RFC 822 email addresses in plain text Release: 0.10-dfsg-2 Source: http://mentors.debian.net/debian/pool/main/l/libemail-find-perl Package Name: libhtml-fromtext-perl Short description: Mark up text as HTML Release: 2.05-6 Source: http://mentors.debian.net/debian/pool/main/l/libhtml-fromtext-perl fix #467908 and #467823 bug. Severity: important Many Thanks :)! Cheers, Francesco -- .''`. ** Debian GNU/Linux ** | Francesco Cecconi ' |BrAnD| ' : :' : The Universal O.S.| [EMAIL PROTECTED] `. `'` | GPG Key ID: 11F6E468 `-*Debian Pkg Maintainer* | JID [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: RFS: swath 0.3.3-1 (updated package)
On Sat, Mar 22, 2008 at 4:38 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: On Sat, 22 Mar 2008 15:37:38 +0900, Paul Wise [EMAIL PROTECTED] wrote: Please fix this GCC warning, after that I will upload: /tmp/buildd/swath-0.3.3/src/wordseg.cpp:244: warning: the use of `tmpnam' is dangerous, better use `mkstemp' This may be better done by a new upstream release. In fact, using mkstemp() instead of tmpnam() means quite substantial change to the program logic, because the temp files are actually created deep in different functions in different branches, using the generated temp names from a single place. Changing that behavior would mean internal API changes. I will come up with a new upstream version soon, then. Err.. I'm not sure if it's appropriate to introduce a big change just to get a serious bug fix delivered. I'm afraid it would risk introducing new bugs working in hurry as well. Here are summarized changes to be done: - mkstemp(), or better yet, tmpfile(), creates the temp file immediately and removes it as soon as it's closed, while current APIs accept file name arguments, create the files for working on and close them when done. Then, another stage opens the files again for working, using the file names arguments, and so on. So, all involved API's must be modified to accept FILE* or file descriptors instead of file names, and their implementations must not close the files when finished, or the files will be deleted and become unavailable for later stages. This involves changing 1 public function, 1 abstract base class and 4 derived classes. - The standard C++ iostream library now doesn't support using fstream with FILE* or file descriptor. (It can only open files with file names.) So, the current code cannot use the file handle or file descriptor returned from tmpfile() or mkstemp() directly without using GNU extension. This may introduce another portability issue, and some configure scripts to check this may be required. With the amount of changes involved, I'm afraid it would take too long for an urgent bug fix, and it would risk introducing new bugs as well. Could we deliver the fix first, and address the issue in next upstream version? Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libemail-find-perl and libhtml-fromtext-perl bug fix update.
On Sat, Mar 22, 2008 at 11:05:56AM +0100, Francesco Cecconi wrote: Hi DD, I'm looking a sponsor for update my perl packages: Package Name: libemail-find-perl Short description: Find RFC 822 email addresses in plain text Release: 0.10-dfsg-2 Source: http://mentors.debian.net/debian/pool/main/l/libemail-find-perl Package Name: libhtml-fromtext-perl Short description: Mark up text as HTML Release: 2.05-6 Source: http://mentors.debian.net/debian/pool/main/l/libhtml-fromtext-perl fix #467908 and #467823 bug. Severity: important Francesco, Let me encourage you to put your packages into the Debian Perl Group's repository. Information can be found here: http://pkg-perl.alioth.debian.org/ You simply need an Alioth account and to send an email to the group's mailing list requsting commit access to teh svn repo. The advantage of doing that is you can simply mark your package as ready for release and then one of the DDs participating in the group will simply sponsor your package for you. No need to upload anywhere. No need to request sponsorship. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: bits from the DMs/NMs/AMs?
On tisdagen den 4 mars 2008, Paul Wise wrote: If you are in NM, a DM, an AM, just having packages sponsored by DDs or maybe recently became a DD, I'd love to hear from you. My AM, Santiago Ruano Rincón (santiago), recently submitted his report to the DAMs, and I thank him for his work. I think the procedure was relatively smooth, but I'm getting a bit worried looking at the queue for DAM approval and the New Maintainers list. The last time a new account (actually, 26 accounts in that batch) was created was on 12 December. Some of the applicants then had waited almost 6 months for DAM approval after the completeness check, and then another 1-3 months for the account to be created. Right now one applicant has waited 8 months for DAM approval, but that may be due to reasons not documented in the DAM/FD Comments section. The DAMs are of course very busy and I don't doubt that they are doing their best processing applications carefully. However, I'm wondering if there might be reason to change some priorities, considering that getting new Developers approved as quickly as possibly (without sacrificing quality), hence increasing manpower, ought to mean time well invested. Also, I note that by getting as far as being recommended by my AM, I should fulfil all the requirements of becoming a DM: * As part of PP, I have digitally signed a statement that I agree to the social contract, the DFSG, and the DMUP, * I have an Advocate and a recommendation by my AM, * my AM has checked that my PGP key is signed by at least one DD. therefore I think that everyone who has got to the DAM approval stage should automatically (or semi-automatically) gain DM status. Earlier steps of the NM and DM procedures could also be integrated. -- Magnus Holmgren[EMAIL PROTECTED] / [EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans signature.asc Description: This is a digitally signed message part.
watchfiles for sourceforge packages
Hi All: Up to recently, I have been using the following watch file URL in the fityk package which is hosted on sourceforge. ftp://heanet.dl.sourceforge.net/f/fi/fityk/fityk-(.*)\.tar\.bz2 As of a short time ago, this no longer works and results in a broken watch file. Does anyone know if this is permanent or alternatively, a better (at least working) URL to use in the watch file? Thanks, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED] http://www.iit.edu/~segre [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: watchfiles for sourceforge packages
On 22/03/2008, Carlo Segre wrote: As of a short time ago, this no longer works and results in a broken watch file. Does anyone know if this is permanent or alternatively, a better (at least working) URL to use in the watch file? man uscan, http://sf.net/ is your friend. Cheers, -- Cyril Brulebois pgpJrvZg1YSiD.pgp Description: PGP signature
RFS: mother
Dear mentors, I am looking for a sponsor for my package mother. * Package name: mother Version : 0.6.4-r4 Upstream Author : Federico Tomassini - Efphe [EMAIL PROTECTED] * URL : http://www.dbmother.org/ * License : BSD Section : python It builds these binary packages: python-mother - Mother is an Object Relational Mapper with strong introspection Description:Mother is an Object Relational Mapper with strong introspection Mother is a Python module that hides SQL syntax and gives you a set of intelligent classes and methods. By `intelligent` we mean that the classes are able to understand autonomously various situations. Think of Mother as an Object Relational Mapper with strong introspection. When dealing with ORMs you usually need configuration files, tables, fields and keys declarations, but not with Mother because Mother knows the database structure herself. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mother - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mother/mother_0.6.4-r4.dsc I would be glad if someone uploaded this package for me. Kind regards Antonio De Luci signature.asc Description: OpenPGP digital signature
Re: RFS: mother
On 22/03/2008, Antonio De Luci wrote: * Package name: mother Version : 0.6.4-r4 Upstream Author : Federico Tomassini - Efphe [EMAIL PROTECTED] * URL : http://www.dbmother.org/ Please remove the homepage from the long description, there's a dedicated “Source” field for that. The long description could be reformatted, so that you leave empty lines, or keep everything in a single paragraph, instead of just going back to the beginning of the next line. The Depends: on psycopg2 looks buggy. Shouldn't it be python-psycopg2 instead? It builds these binary packages: python-mother - Mother is an Object Relational Mapper with strong introspection Description:Mother is an Object Relational Mapper with strong introspection Don't write “foo - foo is a bar” in the short description. “Object Relational Mapper with…” looks better (although I'm not a native English speaker anyway). The package appears to be lintian clean. No. | [EMAIL PROTECTED]:~/tmp/mother-0.6.4$ lintian -i -I | ../mother_0.6.4-r4_i386.changes | wc -l | 31 Why is the revision -r4 anyway? Should be just -4. Also, your diff is empty. Shouldn't you be building a Debian native package if you're including your debian/ directory in the original tarball? Anyway, I'll recommend *not* doing so, and keeping debian/ outside of the tarball, not building a Debian native package. Cheers, -- Cyril Brulebois pgpy4SWxjKO3p.pgp Description: PGP signature
Re: RFS: mother
On 22/03/2008, Cyril Brulebois wrote: [things] Woops, I almost forgot in those few comments that you're not closing your ITP bug in your changelog. Cheers, -- Cyril Brulebois pgpdvjKT5uLuZ.pgp Description: PGP signature
Re: watchfiles for sourceforge packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Carlo. Up to recently, I have been using the following watch file URL in the fityk package which is hosted on sourceforge. ftp://heanet.dl.sourceforge.net/f/fi/fityk/fityk-(.*)\.tar\.bz2 SF.net has a special domain for this. In your case should be (I think I didn't test): http://sf.net/fityk/fityk-([\d\.]+).tar.bz2 The same rule to apply to whatever program on SF.net. Regards. - -- Anibal Avelar (FixXxeR) http://fixxxer.cc GPG: 83B64656 - C143 4AD8 B017 53FA B742 D6AA CEEA F9F3 83B6 4656 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFH5Rmizur584O2RlYRApAaAJ9/ToYVGvqPsrGSbFLOe++Qi5zavgCfT19h KFjIJtOxFDPe1u3KcFwSk88= =C9zT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the DMs/NMs/AMs?
Right now one applicant has waited 8 months for DAM approval, but that may be due to reasons not documented in the DAM/FD Comments section. I'm that person. I'm some disappointed with the process (not with Debian, I love Debian), mainly because I don't receive any type of commentary or feedback. Would be nice to receive some comment (indeed I sent a email to [EMAIL PROTECTED], but I didn't receive nothing). Meanwhile I try to be positive. I continue to learn day to day during this eight months (sending patches to QA, packaging my programs, adopting new packages, looking for sponsors, etc) ;) but yeah, one process more interactive would be nice. Regards. -- Anibal Avelar (FixXxeR) http://fixxxer.cc GPG: 83B64656 - C143 4AD8 B017 53FA B742 D6AA CEEA F9F3 83B6 4656 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swath 0.3.3-1 (updated package)
On Sat, Mar 22, 2008 at 6:38 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: This may be better done by a new upstream release. Indeed. In fact, using mkstemp() instead of tmpnam() means quite substantial change to the program logic, because the temp files are actually created deep in different functions in different branches, using the generated temp names from a single place. Changing that behavior would mean internal API changes. I will come up with a new upstream version soon, then. Ah, hopefully it will not be too much work. Have you considered applying for DM? http://wiki.debian.org/Maintainers Yes, I'll apply soon, but probably not before this upload. I would like to have the regression fixed sooner. Fair enough. BTW, do you think I should raise the urgency from low to medium, although it does not fix any RC bug in Debian BTS? The regression was reported upstream, not in Debian BTS, but it must have been a grave bug had it been filed. It's a total loss of functionality. I think that would be acceptable. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mother
I have followed your advice, please check the new package. It is aligned with the new revision upstream (0.6.4-r5), and I added the revision debian (0.6.4-r5-1). Thanks for your availability It builds these new binary packages: python-mother - Object Relational Mapper with strong introspection The package appears to be lintian clean. The new package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mother - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mother/mother_0.6.4-r5-1.dsc N.B. I am Italian, sorry for the bad English. signature.asc Description: OpenPGP digital signature
Re: RFS: swath 0.3.3-1 (updated package)
On Sat, Mar 22, 2008 at 6:49 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: Err.. I'm not sure if it's appropriate to introduce a big change just to get a serious bug fix delivered. I'm afraid it would risk introducing new bugs working in hurry as well. Here are summarized changes to be done: Update: It seems to require even more changes than I expected. - mkstemp(), or better yet, tmpfile(), creates the temp file immediately and removes it as soon as it's closed, while current APIs accept file name arguments, create the files for working on and close them when done. Then, another stage opens the files again for working, using the file names arguments, and so on. So, all involved API's must be modified to accept FILE* or file descriptors instead of file names, and their implementations must not close the files when finished, or the files will be deleted and become unavailable for later stages. This involves changing 1 public function, 1 abstract base class and 4 derived classes. 1 more base class and 2 more derived classes are found to require such change, totalling in 1 public function, 2 abstract base classes, and 6 derived classes. - The standard C++ iostream library now doesn't support using fstream with FILE* or file descriptor. (It can only open files with file names.) So, the current code cannot use the file handle or file descriptor returned from tmpfile() or mkstemp() directly without using GNU extension. This may introduce another portability issue, and some configure scripts to check this may be required. Even with the GNU extension, it seems impossible to continue using C++ iostream without causing memory leaks, as the fstream destructor always closes the stream, and there is no method to detach the file descriptor to prevent such behavior. Then, a way to leave the file open (so it's not immediately deleted) is to leave the allocated fstream objects undeleted on return. A better way yet is to totally replace C++ iostream with C stdio functions. /me never feels disappointed with C++ like this before. With the amount of changes involved, I'm afraid it would take too long for an urgent bug fix, and it would risk introducing new bugs as well. Could we deliver the fix first, and address the issue in next upstream version? I still think what we need for a seriously broken piece of software is to provide the fix early, rather than develop it that much. So, could you grant the postponement of the gcc warning fix to next upload? Meanwhile, I'm still working on the fix. But as the changes grow, I feel more needs of testing before actually releasing. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: swath 0.3.3-1 (updated package)
On Sun, 23 Mar 2008 11:11:46 +0900, Paul Wise [EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 6:38 PM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: In fact, using mkstemp() instead of tmpnam() means quite substantial change to the program logic, because the temp files are actually created deep in different functions in different branches, using the generated temp names from a single place. Changing that behavior would mean internal API changes. I will come up with a new upstream version soon, then. Ah, hopefully it will not be too much work. I think it should be postponed for now, as explained and requested in another reply. BTW, do you think I should raise the urgency from low to medium, although it does not fix any RC bug in Debian BTS? The regression was reported upstream, not in Debian BTS, but it must have been a grave bug had it been filed. It's a total loss of functionality. I think that would be acceptable. So, I have uploaded a new package with raised urgency. Please find it at the old place: http://mentors.debian.net/debian/pool/main/s/swath/swath_0.3.3-1.dsc debian/changelog timestamp: Sun, 23 Mar 2008 09:30:59 +0700 Thanks, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ signature.asc Description: Digital signature
Re: RFS: swath 0.3.3-1 (updated package)
On Sun, Mar 23, 2008 at 11:46 AM, Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote: So, I have uploaded a new package with raised urgency. Please find it at the old place: http://mentors.debian.net/debian/pool/main/s/swath/swath_0.3.3-1.dsc debian/changelog timestamp: Sun, 23 Mar 2008 09:30:59 +0700 Uploaded. Please ping me on IRC/XMPP when the new upstream version is ready. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mother
Antonio De Luci wrote: I have followed your advice, please check the new package. * debian/control seems to have lost its Homepage field. Cyril suggested that you use the dedicated field, which means: Source: mother Section: python [...] Standards-Version: 3.7.3 Homepage: http://example.com/ * The long description in debian/rules (ie. the text beginning Mother is a Python module...) seems to contain a few spelling, gramatical and formatting errors. I would also suggest you split the description into a couple of paragraphs. This is possible by: |Description: foo bar baz | First paragraph. |. | Second paragraph * Should you really be depending on python-psycopg2 | python-apsw? I would guess that these should be Recommends instead. * README.Debian seems to contain instructions on how to build the Debian package, which seems somewhat superfluous and not-very-useful for users. I would suggest completely removing this file. * debian/copyright: Please don't anti-spam email addresses, it makes searching extremely difficult. Regards, -- Chris Lamb, UK [EMAIL PROTECTED] GPG: 0x634F9A20 signature.asc Description: PGP signature
