Bug#734992: RFS: mapserver/5.6.5-2+squeeze3
Hi Bas, On Sat, Jan 11, 2014 at 05:07:40PM +0100, Bas Couwenberg wrote: Package: sponsorship-requests Severity: normal Dear mentors, The Release Team has approved the proposed update (#734830), so I am looking for a sponsor for my package mapserver Package name: mapserver Version : mapserver/5.6.5-2+squeeze3 Upstream Author : The MapServer team URL : http://www.mapserver.org License : MIT Section : devel [...] The package looks missing from mentors. But I will have a look at it with the given debdiff on the release.d.o bug. Regards, Salvatore -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140111204745.GA16044@eldamar.local
Bug#734992: RFS: mapserver/5.6.5-2+squeeze3
Hi Bas, On Sat, Jan 11, 2014 at 09:47:45PM +0100, Salvatore Bonaccorso wrote: Hi Bas, On Sat, Jan 11, 2014 at 05:07:40PM +0100, Bas Couwenberg wrote: Package: sponsorship-requests Severity: normal Dear mentors, The Release Team has approved the proposed update (#734830), so I am looking for a sponsor for my package mapserver Package name: mapserver Version : mapserver/5.6.5-2+squeeze3 Upstream Author : The MapServer team URL : http://www.mapserver.org License : MIT Section : devel [...] The package looks missing from mentors. But I will have a look at it with the given debdiff on the release.d.o bug. And also uploaded. Thanks for your work. Regards, Salvatore -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140111210242.GA17173@eldamar.local
Bug#697413: RFS: libapp-cpanoutdated-perl/0.24-1 [ITP]
Hi Oleg On Fri, Jan 04, 2013 at 10:32:10PM +, Oleg Gashev wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package libapp-cpanoutdated-perl * Package name: libapp-cpanoutdated-perl Version : 0.24-1 Upstream Author : Tokuhiro Matsuno tokuhirom+c...@gmail.com * URL : http://search.cpan.org/dist/App-cpanoutdated/ * License : Artistic Section : perl It builds those binary packages: libapp-cpanoutdated-perl - detect outdated CPAN modules in your environment To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libapp-cpanoutdated-perl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/liba/libapp-cpanoutdated-perl/libapp-cpanoutdated-perl_0.24-1.dsc Changes since the last upload: * Initial Release. (Closes: #697403) Thanks for your work. Please consider joining the pkg-perl (Debian Perl Group) Team for contributing Perl modules[1]. We are always happy if new people join helping maintaing the Perl modules under the team umbrella. [1]: http://wiki.debian.org/Teams/DebianPerlGroup/Welcome Regards, Salvatore -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130104224839.GA6272@elende
Bug#695626: RFS: lftp/4.3.6-1+deb7u1 [RC] [NMU] [T-P-U]
Hi Ivo On Mon, Dec 10, 2012 at 11:25:12PM +0100, Ivo De Decker wrote: Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my NMU for testing-proposed-updates of lftp. It was approved by the release team: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695152 Thanks for yur work, I see Julien's 'ack'. Unless gregoa comes first, I can do your upload to t-p-u this evening. Regards, Salvatore signature.asc Description: Digital signature
Bug#691893: RFS: roundup/1.4.20-2 [RC]
Hi Kai, hi Mike On Fri, Nov 02, 2012 at 06:35:16PM -0400, Michael Gilbert wrote: On Fri, Nov 2, 2012 at 6:24 PM, Kai Storbeck wrote: Hi Mike, Thanks for your prompt review. It seems I wasn't fully aware of the Freeze Policy. I was under a wrong assumtion that I could make the package's state better during the freeze. I've spoken with Salvatore who proposed an NMU for only the RC bug. I hope he can find the time to upload his proposed patch before the deadline of the 7th. According to the latest traffic in #689257, It sounds like he is deferring to you in terms of uploading a fixed package. Kai had spoken to me regarding the NMU after the last BTS entry yesterday, saying it's fine if I do the upload for only the RC bug. I will upload the NMU this weekend to fix the open RC bug. Regards, Salvatore signature.asc Description: Digital signature
Bug#671745: RFS: logsurfer/1.8-2 [ITP]
Hi Thilo First of all, I have not 'time' probably to full review it and upload, but it's really appreciated that you openend that ITP. On Sun, May 06, 2012 at 05:08:42PM +0200, Thilo Uttendorfer wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package logsurfer Package name: logsurfer Version : 1.8-2 Upstream Author : Kerry Thompsonke...@crypt.gen.nz URL : http://www.crypt.gen.nz/logsurfer/ License : BSD Section : admin It builds those binary packages: logsurfer - Monitoring system logs in real-time To access further information about this package, please visit the following URL: http://mentors.debian.net/package/logsurfer Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/logsurfer/logsurfer_1.8-2.dsc I had a quick look at it and would like to make some suggestions: - I: logsurfer: extended-description-is-probably-too-short Would it be possible to expand the long description, see [1] for some hints [1]. E.g. maybe in a second paragraph or phrase describe what the extra features of logsurfer are (context matching, action). The idea is not to give the contenct of the logsurfer manpage, but give an user some hints on the fatures already in the log description. - short description: could you change it to have it matchng logsurfer is a short description. (e.g. real-time system log monitoring). - Running lintian with '-I' it get the following: I: logsurfer: spelling-error-in-binary usr/bin/logsurfer childs children I: logsurfer: extended-description-is-probably-too-short I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:136 I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:141 I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:145 I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:162 I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:166 I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man1/logsurfer.1.gz:168 I: logsurfer: spelling-error-in-manpage usr/share/man/man1/logsurfer.1.gz expresion expression I: logsurfer: spelling-error-in-manpage usr/share/man/man1/logsurfer.1.gz expresion expression I: logsurfer: FSSTND-dir-in-manual-page usr/share/man/man4/logsurfer.conf.4.gz:249 /var/adm/ I: logsurfer: hyphen-used-as-minus-sign usr/share/man/man4/logsurfer.conf.4.gz:300 It would be great if you could add patches for the spelling errors and sent them to upstream to have them added in their new upstream releases. - logsurfer.conf manpage should go to section 5 'File formats and conventions eg /etc/passwd'. - Generally: For the first upload it would only be neede to have the changelog entry for the Initial upload. Furthermore use (Closes: #) for the closer. Otherwise the changes file will not include the Closes field to close #670875. [1]: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc Thilo, as said I do not have time (at the moment) to fully go trough the package, hope that someone can have a look too. It would be great to have logsurfer in Debian. Regards, Salvatore signature.asc Description: Digital signature
Re: repacking howto
Hi Jermome On Sat, Feb 18, 2012 at 03:34:13AM +0100, Jerome BENOIT wrote: Is the following howto http://pkg-perl.alioth.debian.org/howto/repacking.html still relevant ? This is one possibility to do it. We in the Debian Perl Group are using this procedure/ howto in our packages when repackaging of to tarball is needed. Some further information/hints could be found in the dev-ref [1]. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz Does this helps? Regards, Salvatore signature.asc Description: Digital signature
Re: RFS: libdancer-session-cookie-perl
Hi Alex On Fri, Nov 18, 2011 at 01:03:48PM +0100, Alex Mestiashvili wrote: Dear mentors, I am looking for a sponsor for my package libdancer-session-cookie-perl. * Package name: libdancer-session-cookie-perl Version : 0.15-1 Upstream Author : Alex Kapranoff * URL : http://search.cpan.org/dist/Dancer-Session-Cookie/ http://search.cpan.org/dist/Dancer-Session-Cookie/ * License : GPL-1+ or Artistic Section : perl It builds those binary packages: libdancer-session-cookie-perl - Encrypted cookie-based session backend for Dancer This is a very small but useful perl module which I use personally for my dancer based web app . To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libdancer-session-cookie-perl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libd/libdancer-session-cookie-perl/libdancer-session-cookie-perl_0.15-1.dsc I would be glad if someone uploaded this package for me. First of all thank you for contributing and having begun to package this module. I have not (yet) checked the package, only wonder about the following: Are you interested joining the Debian Perl Group for packaging Perl module and move this unter the umbrella of the pkg-perl team? If so please have a look a our introduction page [1], or our team page [2]. [1] http://wiki.debian.org/Teams/DebianPerlGroup/Welcome [2] http://wiki.debian.org/Teams/DebianPerlGroup In particular we can offer this way an easy sponsorship way. Updated packages ready for review show up on pet [3]. [3] http://pet.debian.net/pkg-perl/pet.cgi All the packages are maintained now in the git repositories for the pkg-perl team, so the git guide might be a good start too [4]. [4] http://pkg-perl.alioth.debian.org/git.html Regards, Salvatore signature.asc Description: Digital signature
Re: RFS: amispammer (updated package)
Hi Julian On Wed, Jul 13, 2011 at 01:03:34AM -0500, Julián Moreno Patiño wrote: Dear mentors, I am looking for a sponsor for the new version 3.2-1 of my package amispammer. It builds these binary packages: amispammer - Powerful Mail Server checker on blacklists 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/amispammer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/amispammer/amispammer_3.2-1.dsc I would be glad if someone uploaded this package for me. I have uploaded the package. Many thanks for your work. Regards Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Sun, Jan 16, 2011 at 09:05:46PM +0100, Julien Palard wrote: I just took some time to work on it, 16 days without any seconds before today ... here it is : Ok great. It took me too a bit to look again at it. One small thing: In debian/watch the regex should be like: ---(debian/watch)--- version=3 http://githubredir.debian.net/github/JulienPalard/logtop/ logtop-(.*).tar.gz On Fri, Dec 31, 2010 at 3:09 PM, Salvatore Bonaccorso car...@debian.org wrote: I was wondering if you could release it as logtop-$version.tar.gz upstream, instead of $version.tar.gz. Ok, i understand, done. With the change to the watch file, then now we should be fine. So it seems, did you added the CHANGELOG afterwards to upstream's tarball? And there are also the .pc directories which should not be therein. Hum I have to put the changlog in the git repository ? It's a bit tricky as git have its own changelog system to maintain a manual changelog file in it ? Whatever, it's done, and i removed the .po in the tarball. Hmm, well the point mostly of upstream changelog file is to see what changed (bugfixes, new features, ...) from versions x to y, but not having all git commits in it. lintian --pedantic -v -iI --display-experimental --show-overrides --checksums --color auto Checked and passed successfully ! Great, it the version I have just checked, all fine here. so please apply only the last change to debian/watch, I will upload then :-). Thanks for your work! Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Peter, and Gregor On Wed, Feb 02, 2011 at 12:01:58PM +0200, Peter Pentchev wrote: On Wed, Feb 02, 2011 at 10:40:46AM +0100, gregor herrmann wrote: On Wed, 02 Feb 2011 11:30:29 +0200, Peter Pentchev wrote: but it would seem that the GNU Coding Standards do not agree - it seems you're doing the right thing with your CHANGELOG file, and the file that Salvatore is talking about ought to be named NEWS. ... which should then be installed as the upstream changelog in /usr/share/doc/pkg/changelog.gz in the Debian package :) Right, I forgot to mention that part. Thanks! :) Thanks for the clarifications! Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Sun, Jan 16, 2011 at 09:05:46PM +0100, Julien Palard wrote: I just took some time to work on it, 16 days without any seconds before today ... here it is : On Fri, Dec 31, 2010 at 3:09 PM, Salvatore Bonaccorso car...@debian.org wrote: I was wondering if you could release it as logtop-$version.tar.gz upstream, instead of $version.tar.gz. Ok, i understand, done. So it seems, did you added the CHANGELOG afterwards to upstream's tarball? And there are also the .pc directories which should not be therein. Hum I have to put the changlog in the git repository ? It's a bit tricky as git have its own changelog system to maintain a manual changelog file in it ? Whatever, it's done, and i removed the .po in the tarball. lintian --pedantic -v -iI --display-experimental --show-overrides --checksums --color auto Checked and passed successfully ! I will try to give feedback and/or upload this weekend! Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Mon, Dec 27, 2010 at 08:45:22AM +0100, Julien Palard wrote: On Sun, Dec 26, 2010 at 1:42 PM, Salvatore Bonaccorso car...@debian.org wrote: I had now time to review the package, sorry for the log delay! Don't worry for this ! - debian/copyright: missing space inbetween first stanza and first Files: stanza. Done Good! - debian/watch: -- v0.1 != 0.1 ... Either change the experession to v(.*) so Done by renaming the tag Ok this is fine. See just below for further comment. Question: is it possible to release upstream's source tar.gz as logtop-$version.tar.gz? So logtop-0.1.tar.gz ? as done here ? I was wondering if you could release it as logtop-$version.tar.gz upstream, instead of $version.tar.gz. Because if someone then downloads upstreams tar.gz with uscan, it is simply downloaded as 0.1.tar.gz. Usually you have the source name too in the tarball. Anyway I noticed the following problem: 08fbc68b118bea6321195b8645ea7643 0.1.tar.gz 3f46c68085940aa7c82191103faec37d logtop_0.1.orig.tar.gz I checked then the content: tar tzvf 0.1.tar.gz drwxrwxr-x root/root 0 2010-12-12 20:57 JulienPalard-logtop-dee72e6/ -rw-rw-r-- root/root 1331 2010-12-12 20:57 JulienPalard-logtop-dee72e6/COPYRIGHT -rw-rw-r-- root/root 662 2010-12-12 20:57 JulienPalard-logtop-dee72e6/Makefile -rw-rw-r-- root/root 3205 2010-12-12 20:57 JulienPalard-logtop-dee72e6/NCURSES_COPYRIGHT -rw-rw-r-- root/root 1360 2010-12-12 20:57 JulienPalard-logtop-dee72e6/README drwxrwxr-x root/root 0 2010-12-12 20:57 JulienPalard-logtop-dee72e6/doc/ -rw-rw-r-- root/root 2084 2010-12-12 20:57 JulienPalard-logtop-dee72e6/doc/logtop.1 drwxrwxr-x root/root 0 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/ -rw-rw-r-- root/root 3867 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/avl.c -rw-rw-r-- root/root 3491 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/curses.c -rw-rw-r-- root/root 4737 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/logtop.c -rw-rw-r-- root/root 2566 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/logtop.h -rw-rw-r-- root/root 2845 2010-12-12 20:57 JulienPalard-logtop-dee72e6/src/stdout.c and tar tzvf logtop_0.1.orig.tar.gz drwxr-xr-x mandark/mandark 0 2010-12-27 08:37 logtop-0.1/ -rw-r--r-- mandark/mandark 1360 2010-12-14 20:47 logtop-0.1/README -rw-r--r-- mandark/mandark 3205 2010-11-13 16:36 logtop-0.1/NCURSES_COPYRIGHT drwxr-xr-x mandark/mandark0 2010-12-20 19:41 logtop-0.1/.pc/ -rw-r--r-- mandark/mandark7 2010-12-14 23:11 logtop-0.1/.pc/.quilt_series -rw-r--r-- mandark/mandark2 2010-12-14 23:11 logtop-0.1/.pc/.version -rw-r--r-- mandark/mandark0 2010-12-20 19:41 logtop-0.1/.pc/applied-patches -rw-r--r-- mandark/mandark 15 2010-12-14 23:11 logtop-0.1/.pc/.quilt_patches drwxr-xr-x mandark/mandark0 2010-12-27 08:31 logtop-0.1/doc/ -rw-r--r-- mandark/mandark 1839 2010-12-27 08:36 logtop-0.1/doc/logtop.1 -rw-r--r-- mandark/mandark 1331 2010-11-13 16:36 logtop-0.1/COPYRIGHT drwxr-xr-x mandark/mandark0 2010-12-27 08:37 logtop-0.1/src/ -rw-r--r-- mandark/mandark 4737 2010-12-14 20:47 logtop-0.1/src/logtop.c -rw-r--r-- mandark/mandark 3491 2010-12-12 00:17 logtop-0.1/src/curses.c -rw-r--r-- mandark/mandark 2845 2010-12-05 20:09 logtop-0.1/src/stdout.c -rw-r--r-- mandark/mandark 3867 2010-12-05 20:09 logtop-0.1/src/avl.c -rw-r--r-- mandark/mandark 2566 2010-12-03 09:57 logtop-0.1/src/logtop.h -rw-r--r-- mandark/mandark 4065 2010-12-17 16:09 logtop-0.1/CHANGELOG -rw-r--r-- mandark/mandark 662 2010-12-15 08:19 logtop-0.1/Makefile So it seems, did you added the CHANGELOG afterwards to upstream's tarball? And there are also the .pc directories which should not be therein. Suggestion: Release upstream a new version adding the CHANGELOG file now, and release it with updated version. - lintian: Checked with --pedantic ! This is not 'enough', because it does not add then the other checks too. I always use somethin like: lintian --pedantic -v -iI --display-experimental --show-overrides --checksums --color auto Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Mon, Dec 20, 2010 at 07:44:25PM +0100, Julien Palard wrote: I rebuilt it from scratch for the moment cause I can't undertand how to rebuild it properly without a debian/patches/debian-changes-0.1-1. So you have a new version to review today. The problem was that the CHANGELOG was not present in the upstream's orig.tar.gz, thus when building the package this was always a debian-change and thus the debian-changes-0.1-1 created. I had now time to review the package, sorry for the log delay! - debian/copyright: missing space inbetween first stanza and first Files: stanza. - debian/watch: -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: http://githubredir.debian.net/github/JulienPalard/logtop/ (.*).tar.gz -- Found the following matching hrefs: /github/JulienPalard/logtop/0~master.tar.gz /github/JulienPalard/logtop/v0.1.tar.gz Newest version on remote site is v0.1, local version is 0.1 = Newer version available from http://githubredir.debian.net/github/JulienPalard/logtop/v0.1.tar.gz -- Downloading updated package v0.1.tar.gz -- Successfully downloaded updated package v0.1.tar.gz and symlinked logtop_v0.1.orig.tar.gz to it -- Scan finished -- v0.1 != 0.1 ... Either change the experession to v(.*) so that the 0.1 is extracted as version. Question: is it possible to release upstream's source tar.gz as logtop-$version.tar.gz? - lintian: N: Processing binary package logtop (version 0.1-1) ... W: logtop: manpage-has-bad-whatis-entry usr/share/man/man1/logtop.1.gz N: N:Each manual page should start with a NAME section, which lists the N:name and a brief description of the page separated by \-. The NAME N:section is parsed by lexgrog and used to generate a database that's N:queried by commands like apropos and whatis. This tag indicates that N:lexgrog was unable to parse the NAME section of this manual page. N: N:For manual pages that document multiple programs, functions, files, or N:other things, the part before \- should list each separated by a comma N:and a space. Each thing listed must not contain spaces; a man page for a N:two-part command like fs listacl must use something like fs_listacl N:in the NAME section so that it can be parsed by lexgrog. N: N:Refer to the lexgrog(1) manual page, the groff_man(7) manual page, and N:the groff_mdoc(7) manual page for details. N: N:Severity: normal, Certainty: certain N: W: logtop: manpage-section-mismatch usr/share/man/man1/logtop.1.gz:5 1 != SECTION N: N:A man page usually should contain a .TH header, specifying the section. N:The section in this manpage doesn't match with the section in the N:filename. N: N:Refer to the groff_man(7) manual page and the man(1) manual page for N:details. N: N:Severity: normal, Certainty: certain N: I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:28 N: N:This manual page seems to contain a hyphen where a minus sign was N:intended. By default, - chars are interpreted as hyphens (U+2010) by N:groff, not as minus signs (U+002D). Since options to programs use minus N:signs (U+002D), this means for example in UTF-8 locales that you cannot N:cut and paste options, nor search for them easily. The Debian groff N:package currently forces - to be interpreted as a minus sign due to N:the number of manual pages with this problem, but this is a N:Debian-specific modification and hopefully eventually can be removed. N: N:- must be escaped (\-) to be interpreted as minus. If you really N:intend a hyphen (normally you don't), write it as \(hy to emphasise N:that fact. See groff(7) and especially groff_char(7) for details, and N:also the thread starting with N:http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01481.h N:tml N: N:If you use some tool that converts your documentation to groff format, N:this tag may indicate a bug in the tool. Some tools convert dashes of N:any kind to hyphens. The safe way of converting dashes is to convert N:them to \-. N: N:Because this error can occur very often, Lintian shows only the first 10 N:occurrences for each man page and give the number of suppressed N:occurrences. If you want to see all warnings, run Lintian with the N:-d/--debug option. N: N:Refer to the groff_char(7) manual page for details. N: N:Severity: wishlist, Certainty: possible N: I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:46 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:50 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:54 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:58 Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Mon, Dec 20, 2010 at 07:44:25PM +0100, Julien Palard wrote: I rebuilt it from scratch for the moment cause I can't undertand how to rebuild it properly without a debian/patches/debian-changes-0.1-1. So you have a new version to review today. I cannot guarantee, but will check if I can review it today. In any case will try to do in next few days. Thanks for your update, will give feedback! Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Wed, Dec 15, 2010 at 08:55:53AM +0100, Julien Palard wrote: Hi Salvatore, I have hard time to understand your last mail, (I'm french, from Paris, so my english is ... frenchy) : I'm neither a native english spaeker, but hope we will manage us to understand each other, im confident :-) On Wed, Dec 15, 2010 at 7:52 AM, wrote: [...] Yes, I would say better. Only one further 'nitpicking' ;-) logtop is a System Administrator tool to analyze line rate taking log file as input. It reads on stdin and print a constantly updated result using curses, displaying in columns: Line number, count, frequency, and the actual line. . $ tail -f FILE | logtop is the friendly version of: $ watch 'tail FILE | sort | uniq -c | sort -gr' Thanks, done Ok! Let me know when you have new version on mentors. Lines starting indeed with two or more spaces, like the last one then, will show up in verbatim. Could you change this this way and the alignment? (and no spaces preferably inbetween the text and ':'). What do you mean about show up in verbatim ? Does the other aren't shown verbatim ? Can't mention this on any doc. Yes, this is explained in Debian Policy, and I can show you an example of what I mean. The Debian Policy part is here [1]. I have two example showing what is meant by 'verbatim'. It is clearly not itself in the debian/control field, but e.g. it is used on webpage, libdigest-md5-file-perl [2], and libformat-human-bytes-perl [3] is using that. You see, the 'code' parts there are then in 'verbatim'. [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description [2] http://packages.debian.org/sid/libdigest-md5-file-perl [3] http://packages.debian.org/sid/libformat-human-bytes-perl Then there is no need for debian/patches/debian-changes-0.1-1 ;-). Oops, was automatically done by dpkg-buildpackage i think, the next time i'll re-run dpkg-buildpackage it will create it again ? do i have to rebuild the package from scratch each time ? Hmm, yes CHANGELOG is an upstream file, so it should be in the upstream tar.gz you provide upstream. For the proposal of DEP5 for machine-readable format-specification, have a lock at [1]. So there are missing the File-Copyright-License stanzas. Could you change this? So have the Format-Specification, Name, Maintainer, Source Stanza, then one for your upstream Files and one separate for the debian/* packaging stanza, and last one the license-'stanza'. Ok, so, as i have some ncurses code, should i make a stanza for ncurses ? But there is no ncurses files in my project, just functions calls, so i can't make any Files section ? Im the same way, does i have to include ncurses_copyright as i done ? So for my own code, can i simply do juste one Files: * section ? and finally, as i have the $package/debian/copyright, is the $package/COPYRIGHT useless ? (it came from the original hierarchy of my project) So, fist of all, no do not remove your copyright statements from upstream! There is also no need then to document the copyright of ncurses. About your question if just one Files: * section is enough, in priciple yes. But please add also the debian/* part even if for the first step you as upstream and you as packager are the same. This is to separate upstream work from packaging work for Debian. Finally, no do not remove COPYRIGHT file from your upstream sources. If I understand your correctly, the problem is a bit, that you are same upstream and packager for Debian in same person. Try to strictly keep them divided. I hope this helps? Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Tue, Dec 14, 2010 at 11:20:14PM +0100, Julien Palard wrote: Hi Salvatore, (and the list) On Wed, Dec 8, 2010 at 9:45 AM, Salvatore Bonaccorso car...@debian.org wrote: Good! It is not mandatory, but see [1,2]. Ok, I don't have to do it manually, just to wrote it in the Changelog to let the packaging system close it for me, juste understood, thanks for all your explanations about this. rewrite the long description. I hope it's better now Yes, I would say better. Only one further 'nitpicking' ;-) logtop is a System Administrator tool to analyze line rate taking log file as input. It reads on stdin and print a constantly updated result using curses, displaying in columns: Line number, count, frequency, and the actual line. . $ tail -f FILE | logtop is the friendly version of: $ watch 'tail FILE | sort | uniq -c | sort -gr' Lines starting indeed with two or more spaces, like the last one then, will show up in verbatim. Could you change this this way and the alignment? (and no spaces preferably inbetween the text and ':'). Yes, that is correct. do not merge them. Upstream changelog is then installed to /usr/share/doc/$package/changelog.gz and Debian's changelog in /usr/share/doc/$package/changelog.Debian.gz. Done using make inatall, am i right ? Hmm, no, as done previously it was correct. Simply have the upstream CHANGELOG in upstream, and the rest will be done by by dh_installchangelogs (see manpage). Then there is no need for debian/patches/debian-changes-0.1-1 ;-). Could you change these two again? For the proposal of DEP5 for machine-readable format-specification, have a lock at [1]. So there are missing the File-Copyright-License stanzas. Could you change this? So have the Format-Specification, Name, Maintainer, Source Stanza, then one for your upstream Files and one separate for the debian/* packaging stanza, and last one the license-'stanza'. [1] http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=135 I would gladly then review! Thanks for logtop and your work so far on getting the package ready! :-) Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Tue, Dec 07, 2010 at 07:39:09PM +0100, Julien Palard wrote: On Tue, Dec 7, 2010 at 10:49 AM, Salvatore Bonaccorso car...@debian.org wrote: Hi Julien Hi Salvatore, I just re-uploaded my packages, fixing things you pointed to me, thank you to have spent time reviewing my package ! [...] - debian/changelog: For first uploads you shoult close an ITP Bug, so close #605904. I Just done it, but as it was not written in the New Debian Maintainer Guide, should I notify someone to add it ? Good! It is not mandatory, but see [1,2]. [1] http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html#s-changelog [2] http://www.debian.org/doc/developers-reference/pkgs.html#newpackage Please note: Bug is then closed when package enters the archive. Do not close it in advance for that. - Is it possible to add some more detailed long description in debian/control? Just done ! Thanks for expanding it. Please have a look at [3,4] further. Important point from dev-ref reccomendation, chapter 6.2.3. The long description. So try further to explain in non-technical ways what the package will do. There are some questions in 6.2.3 which should help rewrite the long description. [3] http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions [4] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-desc-basics - debian/rules: Remove the comments which are not needed. My bad ... just done ! Good! - As you are upstream: Add if possible an upstream Changelog I added the git changelog to the CHANGELOG file, i dont found any help on the Debian New Maintainer Guide on the best practice, just found that i dont have to merge it with the debian/changelog, does i took the right way ? Yes, that is correct. do not merge them. Upstream changelog is then installed to /usr/share/doc/$package/changelog.gz and Debian's changelog in /usr/share/doc/$package/changelog.Debian.gz. See [5] for best practices regarding debian changelog. [5] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-changelog - Would be great if it is also possible to monitor new usptream versions, and so add a debian/watch file I done it : http://githubredir.debian.net/github/JulienPalard/logtop/ (.*).tar.gz And I created the v0.1 tag to my git repository. I am right ? Yes looks fine! - debian/rules: As you are not using override targets, debhelper (= 7) should be enough. OK, done Looks fine! Checking with lintian gives some more hints: My lintian check : lintian -i -I --show-overrides logtop_0.1-1_amd64.changes didn't gave me anything, how can I have the verbose output you have ? Yes, I added some more parameters. I used to check: lintian --pedantic -v -iI --display-experimental --show-overrides I usually, too append --pedantic to the lintian check. Bests Salvatore signature.asc Description: Digital signature
Re: RFS: logtop a realtime log line rate analyzer
Hi Julien On Sun, Dec 05, 2010 at 10:16:49PM +0100, Julien Palard wrote: Dear mentors, I am looking for a sponsor for my package logtop. * Package name: logtop Version : 0.1-1 Upstream Author : Julien Palard * URL : http://github.com/JulienPalard/logtop/ * License : FreeBSD License Section : admin It builds these binary packages: logtop - Realtime log line rate analyzer The package appears to be lintian clean. What this package do ? $ tail -f SOME_FILE | logtop -s X is like doing a : $ watch 'tail -f -n X SOME_FILE | sort | uniq -c | sort -gr' But it updates line by line (curses interface) and display, for each line, the number seen, the number of lines/second, and the line. It was wrote to have a low memory footprint and a low cpu usage, as I is aimed to help sysadmins analyze lots of logs on production server, under heavy load : Log lines are stored in an AVL tree (like a red-black tree but a bit slower to insert, faster to search, as it's better balanced) I use it in production to analyse some logs outputing at a rate 2000 lines / second for example to analyse traffic on my HTTP load balancer (to check if it's normal traffic, watching the top IPs requesting, top pages requested ..., hit rate ratios by page etc...). Combined with grep, logtop can extract interesting information of any kind of log, in realtime with a curses interface using tail -f ... | grep ... | logtop or a one-shot analysis using cat file ... | grep ... | logtop as a final report is dumped to stdout when stdin closes. My motivation for maintaining this package is: I'm the upstream author of this tool that I was seeking for a long time and now that I wrote, and use almost every day. I can't stay without sharing it to the Debian community. It's my first package, and it will make me happy if my little contribution can make some sysadmins happy as I am using Debian ! The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/logtop - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/logtop/logtop_0.1-1.dsc I would be glad if someone uploaded this package for me. You can contact me by mail : reply to this one, or by google talk : mandark.dev or IRC jul1en on freenode and quakenet. I did a short check of your package, not in full details didn't had time to e.g. test it. - debian/changelog: For first uploads you shoult close an ITP Bug, so close #605904. - Is it possible to add some more detailed long description in debian/control? - debian/rules: Remove the comments which are not needed. - As you are upstream: Add if possible an upstream Changelog - Would be great if it is also possible to monitor new usptream versions, and so add a debian/watch file - debian/rules: As you are not using override targets, debhelper (= 7) should be enough. Checking with lintian gives some more hints: W: logtop: manpage-has-bad-whatis-entry usr/share/man/man1/logtop.1.gz W: logtop: manpage-section-mismatch usr/share/man/man1/logtop.1.gz:5 1 != SECTION I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:28 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:46 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:50 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:54 I: logtop: hyphen-used-as-minus-sign usr/share/man/man1/logtop.1.gz:58 P: logtop: no-upstream-changelog W: logtop: new-package-should-close-itp-bug Hope that helps so far Bests Salvatore signature.asc Description: Digital signature
Re: RFS: esmtp (updated package)
Hi all On Sat, Dec 26, 2009 at 03:41:46PM +0100, Salvatore Bonaccorso wrote: I preprared a QA upload for esmtp. I would like to hear some comments, and if you find it ok, to upload it in case. The only thing is missed yet, I know, is updated translations from the debconf templates. I discussed yesterday with Gregor Hermann about it, and adapted three small changes, and he uploaded it for me then. http://packages.qa.debian.org/e/esmtp/news/20091227T171721Z.html Bests Salvatore signature.asc Description: Digital signature
RFS: esmtp (updated package)
Dear mentors,
I'm Cc'in Jose the upstream author, and previous maintainer for esmtp
in Debian, which is now orphaned. See http://bugs.debian.org/561302
I preprared a QA upload for esmtp. I would like to hear some comments,
and if you find it ok, to upload it in case. The only thing is missed
yet, I know, is updated translations from the debconf templates.
The full changelog for the current version I prepared is the
following:
---(debian/changelog)---
esmtp (1.2-1) unstable; urgency=low
* QA upload.
+ Set maintainer to Debian QA Group packa...@qa.debian.org
* New upstream release (Closes: #558390).
* debian/control:
- Bump Build-Depends for debhelper (= 7).
- Add Homepage field.
- Add ${misc:Depends} to Depends field for the esmtp-run binary package
stanza.
- Slightly improve synopsis for esmtp and esmtp-run binary packages.
* Bump compat level for debhelper to 7.
* debian/esmtp.changelogs: Drop ChangeLog from file since this is installed
automatically by dh_installchangelogs.
* Add russian translation for debconf template. Thanks to Yuri Kozlov for
submitting the translation. (Closes: #543186).
* Convert to '3.0 (quilt)' source package format.
* Add patch to fix typo in esmtprc(5) manpage reported by Jakub Wilk.
(Closes: #528343).
* debian/rules: simplify rules makefile to a tiny rules file.
* debian/esmtp.post{inst,rm}: Set the set -e flag to ensure that the script's
execution is aborted when any executed command fails.
* Refresh debian/copyright to the revision 135 of DEP5 proposal for machine
readable format-specification of copyright file.
* debian/esmtp.config: Set explicitly set -e instead of passing -e to the
shell in the shebang.
* Add fix_hyphen-used-as-minus-sign.patch to fix lintian warnings about
missused hyphens in manpages esmtp(1) and esmtprc(5).
* Referesh debian/templates to fix malformed-prompt-in-templates lintian
warnings.
* Switch from _Choices to __Choices in debian/templates spliting choises
list.
* Bump Standards-Version to 3.8.3.
* Add debian/watch file to monitor new upstream versions released.
-- Salvatore Bonaccorso salvatore.bonacco...@gmail.com Sat, 26 Dec 2009
15:15:04 +0100
It builds these binary packages:
esmtp - user configurable relay-only MTA
esmtp-run - user configurable relay-only MTA - the regular MTA
The package appears to be lintian clean.
The upload would fix these bugs: 528343, 543186, 558390
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/e/esmtp
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/e/esmtp/esmtp_1.2-1.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Salvatore Bonaccorso
signature.asc
Description: Digital signature
Re: RFS: googleearth-package
Hi Note I'm not a DD, and I have not carefully looked on all things, only some comments. On Sat, Dec 05, 2009 at 12:34:26PM +0100, ad...@foolcontrol.org wrote: Dear mentors, I am looking for a sponsor for my package googleearth-package. * Package name: googleearth-package Version : 0.5.7 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : contrib/misc This should be filled in normally (but template for new packages) ;-). It builds these binary packages: googleearth-package - utility to automatically build a Debian package of Google Earth The package appears to be lintian clean. The upload would fix these bugs: 551773 I noticed that in source package, in make-googleearth-package script, there is still version 0.5.6 as version string. There is further a changelog.dch.save in source package. But as said, I have not looked deeply into it, and I'm not a DD, so only giving these two comments. Bests Salvatore signature.asc Description: Digital signature
Re: RFS: kabikaboo (lintian)
Hi Dave On Mon, Jun 15, 2009 at 01:45:08PM -0600, Dave Kerr wrote: Could you give me some guidance on new-package-should-close-itp-bug and wrong-bug-number-in-closes l3:#? I read the documentation but I'm unclear if I can submit a bug against my package if the package isn't submitted yet... seems like a catch 22 to me! It says, you diden't (Close #bugnumber_for_itp) use in your debian/changelog. Did you filled allrady a ITP (= Intend To Package= for your package kabikaboo? See [1]. [1] http://www.debian.org/doc/developers-reference/pkgs.html#newpackage You should fill such an ITP for the package, and then close the Bug appropriately in debian/changelog. Does this helps you? Kind regards Salvatore signature.asc Description: Digital signature
Re: RFC for yapet filling debian/copyright
On Sat, Jun 13, 2009 at 04:42:35PM +0900, Charles Plessy wrote: Le Sat, Jun 13, 2009 at 12:01:19AM +0200, Salvatore Bonaccorso a écrit : On Fri, Jun 12, 2009 at 08:33:34PM +0900, Charles Plessy wrote: So you will have something like (in short): Name: YAPET Contact: Rafael Ostertag r...@guengel.ch Source: http://www.guengel.ch/myapps/yapet/ License: GPL-3+ with OpenSSL exception Files: intl/* m4/* License: GPL-2+ Ok, this clearify a bit my question on this. I was really not sure if I need then to clarify each of the intl/* and m4/* if they have slightly different coypright note ... Hi again, I just had another look at your package. The files under m4/* are not under the GPL: Copyright (C) 1995-2007 Free Software Foundation, Inc. This file is free software; the Free Software Foundation gives unlimited permission to copy and/or distribute it, with or without modifications, as long as this notice is preserved. This file can can be used in projects which are not available under the GNU General Public License or the GNU Library General Public License but which still want to provide support for the GNU gettext functionality. According to a recent thread on debian-policy, it may not be necessary to document them. But the final decision is in the hand of the archive administrators when your package is sponsored for the first time. http://lists.debian.org/msgid-search/8763f2pqvk@windlord.stanford.edu Thanks for pointing me to that, I will have a look at this message and will fix the debian/copyright accordingly. If the files in intl/* are unused, then actually the above might apply as well. But I recommend to document their copyright and add a comment explaining that they are not used, in order to show that you actually verified that there is no problem and save other people's time. This sounds like a good idea to add such a good comment and document them anyway. It is indeed not my intention to waste the time of the people who will check the package! Many thanks for your checking and comments, I will try to finalize the packaging this weekend. Kind regards Salvatore signature.asc Description: Digital signature
RFC for yapet filling debian/copyright
Hi I'm working on packaging yapet, which is not yet ready for requesting sponsoring. I have a question regarding filling debian/copyright. The source package is located on mentors.d.n [1]. [1] http://mentors.debian.net/debian/pool/main/y/yapet/yapet_0.3a-1.dsc Now, my question is about filling the debian/copyright. The overall license for yapet is GPL-3+ with the OpenSSL exception. This was changed upstream, after I informed him, about that issue. Now I'm unsure in this case if it is enough to state for File: * GPL-3+ with the OpenSSL exception, or if I really should separate these out, filling new stanza in debian/copyright. The second question is, how to handle the copyright for the files in intl/ and m4/ directories. In particular, some of them have the same license, but different copyright years, should then this really be separated into stanzas of the copyright files, or is it enough to state the most covering time intervall? And should be autogeneratd files as aclocal.m4 which containts a copyright statement in the hader also be included into debian/copyright? Many thanks for helping out on this Kind regards Salvatore signature.asc Description: Digital signature
Re: RFC for yapet filling debian/copyright
Dear Charles Many thanks for your reply on this. On Fri, Jun 12, 2009 at 08:33:34PM +0900, Charles Plessy wrote: Le Fri, Jun 12, 2009 at 08:12:46AM +0200, Salvatore Bonaccorso a écrit : [...] The second question is, how to handle the copyright for the files in intl/ and m4/ directories. In particular, some of them have the same license, but different copyright years, should then this really be separated into stanzas of the copyright files, or is it enough to state the most covering time intervall? And should be autogeneratd files as aclocal.m4 which containts a copyright statement in the hader also be included into debian/copyright? from my understanding of the GPL, as a distributor you do not have particular obligations to display copyright informations in the binary packages (it is the program that must be able, and anyway the sources must come together). For the source package, the copyright informations have to be displayed “appropriately”. My personal point of view is that what was good for Upstream is good for us. But in parallel to the program's license(s), you also have obligations from the Debian Policy and the archive administrators. In practice, no package has been rejected for not including information about the autoconf files, so if you do not feel like including them, it should be safe. For the GPL-2 files in intl/ and m4/, I think that it is up to you to document or not the copyright holders, but you have to document the license. So you will have something like (in short): Name: YAPET Contact: Rafael Ostertag r...@guengel.ch Source: http://www.guengel.ch/myapps/yapet/ License: GPL-3+ with OpenSSL exception Files: intl/* m4/* License: GPL-2+ Ok, this clearify a bit my question on this. I was really not sure if I need then to clarify each of the intl/* and m4/* if they have slightly different coypright note ... And now, there may be a problem: if the files of intl/* are linked to the code with OpenSSL exception, they will not inherit it (this is where looking who holds the copyright gets some importance). So if they end up in linked to OpenSSL in the same program, it is probably unredistributable. But this is not a bad news intl/ is shipped in upstream tarball, but is not used during buildprocess, since I use Use included libintl: no (see attached buildlog). Is this correct? Many thanks for your help so far Kind regards Salvatore yapet_0.3a-1_i386.build.gz Description: Binary data signature.asc Description: Digital signature
Re: RFS: iulib (2nd attempt)
Hi Jeffrey First, I'm not a DD! On Tue, Jun 09, 2009 at 09:42:00PM +0200, Jeffrey Ratcliffe wrote: Dear mentors, I am looking for a sponsor for my package iulib. * Package name: iulib Version : 0.3-1 Upstream Author : Thomas Breuel * URL : http://code.google.com/p/iulib/ * License : Apache-2.0 Section : graphics It builds these binary packages: libiulib - a library of image understanding-related algorithms libiulib-dev - a library of image understanding-related algorithms -- development files I shortly looked into it, you seem to use a unmodified tiny debian/rule. You should minimize this, by using only a mini-debian/rule and depend in debian/control on (debhelper = 7.0.8, please check the correct version in changelog of debhelper) - it will look then like: You also need the dependency on newest quilt for that in debian/control. ---(debian/rules)--- #!/usr/bin/make -f %: dh --with quilt $@ As said, this is only a hint on the small dh7 debian/rules :-) Kind regards Salvatore signature.asc Description: Digital signature
RFS: libconfig-grammar-perl
Dear mentors, I am looking for a sponsor for my package libconfig-grammar-perl. * Package name: libconfig-grammar-perl Version : 1.10-1 Upstream Author : David Schweikert da...@schweikert.ch and contributions from Tobias Oetiker and Niko Tyni * URL : http://search.cpan.org/dist/Config-Grammar/ * License : GPL-1+ or Artistic (same as Perl) Section : perl It builds these binary packages: libconfig-grammar-perl - A grammar-based user-friendly config parser Long description (from package): Config::Grammar is a module to parse configuration files. The configuration may consist of multiple-level sections with assignments and tabular data. The parsed data will be returned as a hash containing the whole configuration. Config::Grammar uses a grammar that is supplied upon creation of a Config::Grammar object to parse the configuration file and return helpful error messages in case of syntax errors. Using the makepod method you can generate documentation of the configuration file format. . The maketmpl method can generate a template configuration file. If your grammar contains regexp matches, the template will not be all that helpful as Config::Grammar is not smart enough to give you sensible template data based in regular expressions. The related function maketmplmin generates a minimal configuration template without examples, regexps or comments and thus allows an experienced user to fill in the configuration data more efficiently. Rationale: We use Config::Grammar for some of the important tools in our system administration toolchest [0]. David worked in previous years in the same group and so developped many of these tools, many of them using the Config::Grammar Perl module. [0] http://isg.ee.ethz.ch/tools/isgtc/index.cgi The package appears to be lintian clean. The upload would fix these bugs: 530937 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libconfig-grammar-perl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libconfig-grammar-perl/libconfig-grammar-perl_1.10-1.dsc I would be glad if someone uploaded this package for me. Kind regards and thanks Salvatore Bonaccorso signature.asc Description: Digital signature
Re: RFS: libconfig-grammar-perl
Hi On Fri, May 29, 2009 at 09:22:27AM +0200, Salvatore Bonaccorso wrote: Dear mentors, I am looking for a sponsor for my package libconfig-grammar-perl. * Package name: libconfig-grammar-perl Version : 1.10-1 Upstream Author : David Schweikert da...@schweikert.ch and contributions from Tobias Oetiker and Niko Tyni * URL : http://search.cpan.org/dist/Config-Grammar/ * License : GPL-1+ or Artistic (same as Perl) Section : perl It builds these binary packages: libconfig-grammar-perl - A grammar-based user-friendly config parser [...] The package appears to be lintian clean. The upload would fix these bugs: 530937 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libconfig-grammar-perl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libconfig-grammar-perl/libconfig-grammar-perl_1.10-1.dsc I would be glad if someone uploaded this package for me. A short note on my request, I asked the pkg-perl group if I can be added to the project group, and thus it would be in the pkg-perl svn repository. Kind regards Salvatore signature.asc Description: Digital signature
Re: architecture wildcards, type-handling, etc.
Hi Ok, p-a-s means Packages-arch-specific, as Paul Wise explained. On Tue, May 19, 2009 at 06:43:19AM +0200, Laurent Guignard wrote: On Thu, 14 May 2009 19:25:46 +0200, Salvatore Bonaccorso wrote: On Thu, May 14, 2009 at 04:26:56PM +0200, Cyril Brulebois wrote: brian m. carlson sand...@crustytoothpaste.ath.cx (14/05/2009): I've worked on FTBFS-with-new-GCC bugs before, and realized only after putting significant work into the bug that the package didn't build on amd64, only on i386. Therefore, I think that the package should have a proper list of archs that prevents this problem. P-a-s is fine for the buildds, but if you actually want people to volunteer to fix bugs on your package, you shouldn't make it harder on them. Which is why people are expected to: - Make their packages FTBFS ASAP in the build system, to make it obvious it's not intended to even be tried on $archs. - Then get the P-a-s entry added. Could that a bit be explainend? I do not understand the following: Assuming I have a package, which I know it is only working under i386 and amd64, but has the bug that it builds correctly on another architecture (but is then not usable there), does this mean, that I should not put only i386 and amd64 in Architecture field, but instead nevertheless let any by in the Architechture field, but then on build time, let the build fail on say powerpc? Ok, thanks for the explaiaintion. I tried to search in the policy regarding that, but didn't find it at the moment, but will check again with your hint. I'm also only at the beginning. Indeed the question is not only hippotetical, since such a question affects one of my packages. So I wondered what Cyril Brulebois meant exaclty, since I didn't understand exactly. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: udav
Hi all On Mon, May 11, 2009 at 03:26:59PM +0200, Salvatore Bonaccorso wrote: I asked Alexey if that would be possible. I hope the point's can be solved by using icons known to be in the public domain. So I have to wait for his reply on this. Short note, Alexey had now most of the icons repladed, there we search only for three further ones: export, import and transparency. The other point to explain how icons from mathgl scripts are generated is also in progress. Bests Salvatore signature.asc Description: Digital signature
Re: RFS: debsigs (adopted, fixed bugs, updated)
Hi On Sun, May 17, 2009 at 07:41:44AM +1000, Matthew Palmer wrote: On Sat, May 16, 2009 at 06:44:54PM +0300, Peter Pentchev wrote: The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/d/debsigs/debsigs_0.1.15.dsc curl: (22) The requested URL returned error: 404 dget: curl debsigs_0.1.15.dsc http://mentors.debian.net/debian/pool/main/d/debsigs/debsigs_0.1.15.dsc failed Has this already been uploaded? It seems yes! http://packages.qa.debian.org/d/debsigs/news/20090516T180202Z.html Bests Salvatore signature.asc Description: Digital signature
Re: architecture wildcards, type-handling, etc.
Dear reader of debian-mentors, I read the following, following a discussion on debian-devel, which I do not understand. On Thu, May 14, 2009 at 04:26:56PM +0200, Cyril Brulebois wrote: brian m. carlson sand...@crustytoothpaste.ath.cx (14/05/2009): I've worked on FTBFS-with-new-GCC bugs before, and realized only after putting significant work into the bug that the package didn't build on amd64, only on i386. Therefore, I think that the package should have a proper list of archs that prevents this problem. P-a-s is fine for the buildds, but if you actually want people to volunteer to fix bugs on your package, you shouldn't make it harder on them. Which is why people are expected to: - Make their packages FTBFS ASAP in the build system, to make it obvious it's not intended to even be tried on $archs. - Then get the P-a-s entry added. Could that a bit be explainend? I do not understand the following: Assuming I have a package, which I know it is only working under i386 and amd64, but has the bug that it builds correctly on another architecture (but is then not usable there), does this mean, that I should not put only i386 and amd64 in Architecture field, but instead nevertheless let any by in the Architechture field, but then on build time, let the build fail on say powerpc? Many thanks Salvatore btw, what p-a-s mean in this context? signature.asc Description: Digital signature
Re: RFS: libpam-alreadyloggedin
Hi Jakub (I'm not a DD) On Tue, May 12, 2009 at 09:11:15AM +0200, Jakub Wilk wrote: Dear mentors, I am looking for a sponsor for my package libpam-alreadyloggedin. * Package name: libpam-alreadyloggedin Version : 0.3-1 Upstream Author : Ilya Evseev * URL : http://ilya-evseev.narod.ru/posix/pam_alreadyloggedin/ * License : BSD Section : admin It builds these binary packages: libpam-alreadyloggedin - PAM module to skip password authentication for logged users The package appears to be lintian clean. Only a short note on that, the source package fails to build in a clean pbuilder environment with: make[1]: Entering directory `/tmp/buildd/libpam-alreadyloggedin-0.3' gcc -c -g -O2 -Wall -fPIC -DLINUX_PAM -I. -DBUG_STAT_MISSING pam_alreadyloggedin.c pam_alreadyloggedin.c:70:31: error: security/pam_appl.h: No such file or directory pam_alreadyloggedin.c:71:34: error: security/pam_modules.h: No such file or directory pam_alreadyloggedin.c:72:31: error: security/pam_misc.h: No such file or directory pam_alreadyloggedin.c:151: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int' pam_alreadyloggedin.c:206: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int' make[1]: *** [pam_alreadyloggedin.o] Error 1 make[1]: Leaving directory `/tmp/buildd/libpam-alreadyloggedin-0.3' dh_auto_build: make returned exit code 2 make: *** [build-stamp] Error 1 There seems to be a missing Build dependency on at least libpam0g-dev. Hope that helps Bests Salvatore signature.asc Description: Digital signature
Re: RFS: udav
Hi Paul I asked Alexey if that would be possible. I hope the point's can be solved by using icons known to be in the public domain. So I have to wait for his reply on this. Bests Salvatore On Mon, May 11, 2009 at 11:07:12AM +0800, Paul Wise wrote: On Mon, May 11, 2009 at 2:15 AM, Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote: At this time I was again in contact with Alexey, the upstream author. He explained me the following regarding the icons: 8 The icon udav.png is generated by UDAV itself (or via mgl2png, as independent MathGL tool). The source code is in attachment. I can add this script to the source archive too. Please ask him to include the source and the instructions for regenerating it in the tarball and VCS. Other icons (for toolbars) I made by myself (arrows, cinema, options, lighting and so on) but some of them (specifically new/load/save/find/undo/redo/cut/copy/paste/help) I got from an icon archive. Unfortunately, now I don't remember the source -- I'm ready to replace it for any other similar icons. OK, the icon archive ones are most likely quite problematic (copyright Microsoft or something). Perhaps Qt provides a way to get standard icons for the platform? Alternately depend on or use icons from the tango icon library, which is now public domain: http://tango.freedesktop.org/ http://tango.freedesktop.org/Tango_Icon_Library Most of pictures in help/pics/ was generated by UDAV itself -- it is just color schemes. If you need I can provide the script(s) for its generation. Some pictures (with symbols) was generated by latex -- when I port the documentation from latex-based to texinfo-based and/or html-based. Please ask him to include the source and the instructions for regenerating them in the tarball and VCS. This includes the latex source 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 -- .-. oo| Debian GNU/Linux -- The power of freedom -- /`'\ GPG key ID: 0x7FD863FEhttp://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 04A4 407C B914 2C23 030C 17AE 789D 6F05 7FD8 63FE signature.asc Description: Digital signature
Re: RFS: udav
Hi Paul and all Ok, thanks again for your reply and your interest! (And sorry for this late response, I was on holidays last week). On Tue, May 05, 2009 at 01:12:06PM +0800, Paul Wise wrote: On Mon, May 4, 2009 at 3:20 AM, Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote: I uploaded a new fixed version to mentors.debian.net dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc Some more things: Some of the images in help/pics/ contain this comment but there doesn't seem to be any source code for them nor any indication of how they were generated (other than using ghostscript). Image generated by GPL Ghostscript (device=pnmraw) While upstream's udav.png doesn't contain this comment, it does use transparency and what looks like a 3D effect, is there any source code for that? The file*.xpm and other icons look suspiciously like the icons from Windows 3.1 (or Win95, not sure). I really can't say anything about that, but I forwarded these questions to the upstream author, to hopefully be clarified in future. The icons stuff needs fixing, I suggest the following: udav.desktop Icon=udav udav.menu icon16x16=/usr/share/icons/hicolor/16x16/apps/udav.xpm udav.menu icon32x32=/usr/share/icons/hicolor/32x32/apps/udav.xpm install src/udav.png /usr/share/icons/hicolor/64x64/apps/udav.png install src/xpm/udav.xpm /usr/share/icons/hicolor/16x16/apps/udav.xpm convert -scale 32x32 src/udav.png /usr/share/icons/hicolor/32x32/apps/udav.png convert -scale 32x32 src/udav.png /usr/share/icons/hicolor/32x32/apps/udav.xpm I changed these as you suggested. desktop-file-validate complains: $ desktop-file-validate debian/*.desktop debian/udav.desktop: warning: value Application;Education;Science;Math; for key Categories in group Desktop Entry contains a deprecated value Application Here I wasn't aware of this tool desktop-file-validate, thanks a lot. When doing the desktop file I followed [1] but I think I mixed some stuff ... it is now fixed. [1] http://standards.freedesktop.org/menu-spec/latest/apa.html The blank lines in the desktop file aren't needed. Removed Be sure to send the .desktop file upstream. Yes will do! There are some gcc warnings: qmglcanvas.cpp:187: warning: unused parameter 'mes' mgl_addon.cpp:53: warning: unused parameter 'lib' mgl_addon.cpp:53: warning: unused parameter 'func' Upstream informed about that. And a dpkg-shlibs warning: dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/udav/usr/bin/udav were not uselessly linked against it (they use none of its symbols). Also noticed upstream. DH_VERBOSE is usually off and only turned on for debugging. It is removed now from debian/rules and will switch it only on when debugging. Sourceforge bug URLs can be reduced to this: http://sf.net/support/tracker.php?aid=1234 Thanks, also here didn't know that. It is fixed in the patch. (btw. Alexey the upstream author already commited it and should be ok in the next version of udav, also the problem with the .svn directories in source tgz). The new fixed version is uploaded to mentors.d.n: dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc Bests Salvatore signature.asc Description: Digital signature
Re: RFS: udav
Hi Paul and all others Here some further notes on the issues you mentioned! On Sun, May 10, 2009 at 11:14:54AM +0200, Salvatore Bonaccorso wrote: On Tue, May 05, 2009 at 01:12:06PM +0800, Paul Wise wrote: On Mon, May 4, 2009 at 3:20 AM, Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote: I uploaded a new fixed version to mentors.debian.net dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc Some more things: Some of the images in help/pics/ contain this comment but there doesn't seem to be any source code for them nor any indication of how they were generated (other than using ghostscript). Image generated by GPL Ghostscript (device=pnmraw) While upstream's udav.png doesn't contain this comment, it does use transparency and what looks like a 3D effect, is there any source code for that? The file*.xpm and other icons look suspiciously like the icons from Windows 3.1 (or Win95, not sure). I really can't say anything about that, but I forwarded these questions to the upstream author, to hopefully be clarified in future. At this time I was again in contact with Alexey, the upstream author. He explained me the following regarding the icons: 8 The icon udav.png is generated by UDAV itself (or via mgl2png, as independent MathGL tool). The source code is in attachment. I can add this script to the source archive too. Other icons (for toolbars) I made by myself (arrows, cinema, options, lighting and so on) but some of them (specifically new/load/save/find/undo/redo/cut/copy/paste/help) I got from an icon archive. Unfortunately, now I don't remember the source -- I'm ready to replace it for any other similar icons. Most of pictures in help/pics/ was generated by UDAV itself -- it is just color schemes. If you need I can provide the script(s) for its generation. Some pictures (with symbols) was generated by latex -- when I port the documentation from latex-based to texinfo-based and/or html-based. 8 So the udav.png itself is generated by a MGL script, and then converted via mg2png (mgl2png is in the mathgl package!). How should I procede with this, what would you suggest? The MGL script udav.mgl was allready commited to svn (revision 25) if necessary, but in particular with the other ones (new, load, save, ...). The third group of icons, is again generated by UDAV itself. There are some gcc warnings: qmglcanvas.cpp:187: warning: unused parameter 'mes' mgl_addon.cpp:53: warning: unused parameter 'lib' mgl_addon.cpp:53: warning: unused parameter 'func' Upstream informed about that. Regarding this, Alexey said to me, that he cleaned up a bit the code in svn. so in next version of udav released these warnings should not appear anymore. Bests Salvatore setsize 64 64 new xx 30 30 new yy 30 30 new zz 30 30 new cc 30 30 new x 90 new y 90 new z 90 new r 90 modify x 'cos(4*pi*x)*exp(-2*x)' modify y 'sin(4*pi*x)*exp(-2*x)' modify z '1.8*x-1' modify r '0.2*exp(-2*x*x)' # for =32 zoom 0.35 0.33 0.7 0.68 #rect -1 -1 -1 1 1 -1 'W' alpha on modify xx '0.05+0.6*x*cos(2*pi*y)' modify yy '0.6*x*sin(2*pi*y)' modify zz '-1' modify cc '1-2*x*x' surfa xx yy zz cc 'y' alpha off axis -2 -2 -2 2 2 2 # test light on rotate 60 -10 tube x y z r 'b#' modify xx '0.2*sin(pi*x)*cos(2*pi*y)+exp(-2)' modify yy '0.2*sin(pi*x)*sin(2*pi*y)' modify zz '0.8-0.2*cos(pi*x)' surf xx yy zz 'r' modify xx '0.2*sin(pi*x)*cos(2*pi*y)+1' modify yy '0.2*sin(pi*x)*sin(2*pi*y)' modify zz '-1-0.2*cos(pi*x)' surf xx yy zz 'b' #new a 40 40 #modify a '1*rnd-1' #smooth a 2 #alpha on #surf a 'blc' signature.asc Description: Digital signature
Re: Bug#510377: RFS: udav
Hi Paul Thanks a lot for your feedback on the packaging for udav. On Sun, May 03, 2009 at 11:45:21AM +0800, Paul Wise wrote: Some feedback based on the diff.gz: Please get your package description reviewed by the debian-l10n-englist email list, it contains some gramatical errors. I sent a review request on the debian-l10n list. I'm not a native english speaker, so I will follow that. I just sent a request for review on the debian-i18n list. Is it really nessecary to repack a tarball just to remove .svn directories? I suggest just asking upstream to use whatever the equivalent of 'make dist' is for qmake and using their orig tarball. As explained in IRC on #debian-mentors: I contacted upstream about that. Previous tgz didn't contain them, so I suppose there was a mistake when packaging the source, but I'm not quite sure. But I did not get a answer so far. It might be a good idea to put an icon in the menu file. From the upstream screenshots it looks like they have one you could use. Please add a FreeDesktop menu file too, otherwise udav will not be visible from the GNOME/LXDE menus. I will correct this, it's a good idea. ChangeLog.txt should be a parameter to dh_installchangelogs instead of in debian/docs. Have allready changed this. The manual page isn't that useful upstream, but they might be interested in it, with or without some changes. Ok, so I will sent this upstream. Lintian complaints: X: udav: spelling-error-in-binary ./usr/bin/udav usefull useful Can I ask you how you did check that? I always use the following for my lintian checks before requesting sponsoring for a package and also for new uploads to review by a sponsor: lintian --pedantic -v -iI package_version*ch* How the above spelling-error-in-binary was done? Bests and thanks Salvatore signature.asc Description: Digital signature
Re: RFS: udav
Hi Paul and all On Sun, May 03, 2009 at 11:45:21AM +0800, Paul Wise wrote: On Sun, May 3, 2009 at 6:39 AM, Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote: - dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc Some feedback based on the diff.gz: Please get your package description reviewed by the debian-l10n-englist email list, it contains some gramatical errors. I got a review, and adapted the control file. Is now more correctly? It might be a good idea to put an icon in the menu file. From the upstream screenshots it looks like they have one you could use. Please add a FreeDesktop menu file too, otherwise udav will not be visible from the GNOME/LXDE menus. As you suggested I have now an icon file into the Debian menu, and also added a udav.desktop file for the GNOM/LXDE menu entries. ChangeLog.txt should be a parameter to dh_installchangelogs instead of in debian/docs. Yes this was an error, I fixed this now and use dh_installchangelogs instead. The manual page isn't that useful upstream, but they might be interested in it, with or without some changes. I've sent it to upstream, if they want to use (but is not really filled with content, it only hints to the documentation). Lintian complaints: X: udav: spelling-error-in-binary ./usr/bin/udav usefull useful If fixed that via quilt patch, and sent the patch also upstream. Thanks for pointing to the --display-experimental of lintian. I uploaded a new fixed version to mentors.debian.net dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc Best regards Salvatore signature.asc Description: Digital signature
Re: RFS: bosh
Hi On Sat, May 02, 2009 at 11:11:00AM +0200, Patrick Matthäi wrote: Salvatore Bonaccorso schrieb: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bosh - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bosh/bosh_0.6-1.dsc I would be glad if someone uploaded this package for me. Uploaded. Thanks Patrick. Bests Salvatore signature.asc Description: Digital signature
RFS: udav
Dear mentors, I am looking for a sponsor for my package udav. * Package name: udav Version : 0.5.1-1 Upstream Author : Alexey Balakin bala...@appl.sci-nnov.ru * URL : http://udav.sourceforge.net/ * License : GPL Section : math It builds these binary packages: udav - data visualization based on MathGL The package appears to be lintian clean. The upload would fix these bugs: 510377 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/udav - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/udav/udav_0.5.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
RFS: bosh
Dear mentors, I am looking for a sponsor for my package bosh. * Package name: bosh Version : 0.6-1 Upstream Author : Alex Sisson alexsis...@gmail.com * URL : http://bosh.sourceforge.net/ * License : GPL-2+ Section : utils It builds these binary packages: bosh - browse output of processes The package appears to be lintian clean and build in a sid chroot with pbuilder. The upload would fix these bugs: 519413 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bosh - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bosh/bosh_0.6-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
Re: pbuilder and building a package twice in a row with hook-skript?
Hi Ben On Thu, Mar 19, 2009 at 10:05:07AM +1100, Ben Finney wrote: Salvatore Bonaccorso salvatore.bonacco...@gmail.com writes: cd /tmp/buildd PKGNAMES=$(ls -d */) for PKG in $PKGNAMES; do if [ -d $PKG ]; then cd $PKG dpkg-buildpackage -tc fi done I'm not sure why you get the names that are directories (‘ls -d */’), but then also test each one to see if it's a directory. Indeed yes, that's a bit non-sense. Thanks for the better version of that. Bests Salvatore signature.asc Description: Digital signature
Re: pbuilder and building a package twice in a row with hook-skript?
Hi alltogether On Thu, Mar 19, 2009 at 10:47:24PM +1100, Ben Finney wrote: On jeu, 19 mar 2009 12:28:02 +1100, Ben Finney wrote: Hmm. When I try this on some of my packages it fails, because apparently ‘dpkg-buildpackage -tc’ isn't how ‘pbuilder’ is running the program. How, within a pbuilder hook program, can I get the complete command line that pbuilder uses to invoke ‘dpkg-buildpackage’? Ithink you can find more information about this in : /usr/sbin/pbuilder and /usr/lib/pbuilder/pbuilder-buildpackage Hope this will help. It helps a little, but AFAICT the command line is not actually available for use by the hook program. Am I missing something? This problem is still fuzzy for me. I've never been sure exactly what the precise sequence we're supposed to test actually *is*. While people have been happy to say “try a pbuilder hook”, what should that hook *do*, exactly? Build the package twice — but with what exact command line? Should the first be different from the second? Looking at ‘pbuilder-buildpackage’, it doesn't use the ‘-tc’ option to clean the source tree after build; does that mean pbuilder is not the right tool here? Or not its default configuration? If not, then what tool has been revealing the bugs that lead to this whole issue of double-build failures? I think that is a really good point you observed. How is the check does it build twice in a row cleanly really done when tested when rebuild of the whole archive was done? Bests Salvatore signature.asc Description: Digital signature
Re: pbuilder and building a package twice in a row with hook-skript?
Hi Laurent On Wed, Mar 18, 2009 at 02:07:41PM +0100, Laurent Guignard wrote: On lun, 16 mar 2009 08:08:08 +0100, Salvatore Bonaccorso wrote: I would like to be able to build package in pbuilder chroot if possible twice in a row, to test them for that. I read on several part that this should easily be done with a hook scrpipt for pbuilder. See e.g. http://lists.debian.org/debian-mentors/2008/10/msg00237.html There is also: bugs.debian.org/490935 Does someone do it this way? If yes, do you have any hint for me, how to do this? Is there a best practice, when wanted to do and test this in pbuilder environment? Bests and thanks for all the help on -mentors! Salvatore I post on my blog the script i usually use. May be you will have to adapt it to your needs. If you improve it, could you post and/or mail me your updates. As i will be able to study your updates and will learn of. Thanks for that your script. I solved it now by a script changing to /tmp/buildd/package-version, and rebuilding then in the chroot again the package, to build twice in a row. Then using --hookdir of pbuilder to pass the directory where these hookscripts are stored. Basically I will do in a B-hook-script the following, but is not yet perfect :( cd /tmp/buildd PKGNAMES=$(ls -d */) for PKG in $PKGNAMES; do if [ -d $PKG ]; then cd $PKG dpkg-buildpackage -tc fi done Bests Salvatore -- .-. oo| Debian GNU/Linux -- The power of freedom -- /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: _i368
Hi On Tue, Mar 17, 2009 at 08:02:20AM +0100, Jaromír Mikeš wrote: I just build package and this having suffix i386 even I set debian/control Architecture: any and in debian/rules I put all dh_scripts to binary-indep section. If the package is architecture independent, then Architecture should be all, not any. See debian-policy 5.6.8 Archtiecture [1] for reference. [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture Does this helps you? Bests Salvatore signature.asc Description: Digital signature
pbuilder and building a package twice in a row with hook-skript?
Hi I would like to be able to build package in pbuilder chroot if possible twice in a row, to test them for that. I read on several part that this should easily be done with a hook scrpipt for pbuilder. See e.g. http://lists.debian.org/debian-mentors/2008/10/msg00237.html There is also: bugs.debian.org/490935 Does someone do it this way? If yes, do you have any hint for me, how to do this? Is there a best practice, when wanted to do and test this in pbuilder environment? Bests and thanks for all the help on -mentors! Salvatore signature.asc Description: Digital signature
Re: How handle Architecture when package is restricted/limited to only some archs?
Hi Don Armstrong and all, On Sun, Feb 01, 2009 at 11:51:08PM -0800, Don Armstrong wrote: On Mon, 02 Feb 2009, Salvatore Bonaccorso wrote: tuxcmd is currently by upsteam restricted to the Architectures i386 and x86_64. [1]. As suggested in a previous thread I had put Architecture: any in the control file, and now I'm having the following situation: On powerpc all Build-Depends are satisfied, and also the package get's build, but tuxcmd will not work at all on this architecture. Why not? There's nothing obvious about tuxcmd that makes it only suitable for i386 and amd64. If it doesn't work properly on archs other than i386 and amd64, that sounds like bugs that should be fixed (likely resulting from poor coding practices on the part of upstream.) I got recently now also an answer from upstram author on this restricted support on only little endian architectures. It is: yes, PowerPC port is currently broken. FreePascal has very bad support for different endianity, mostly from the memory management point of view. I had partial success some time ago on an old iBook G3 though, no plugins. FreePascal internally allocates memory from heap (most probably), but from different memory area than malloc does. It also adds few bytes control information and returns pointer with offset of few bytes, which obviously cannot be used with standard libc allocator calls. I had no luck with FPC cmem unit either which basically uses malloc, things went even worse. Spending so much time on fixing things which are broken from the beginning is unproductive and there are different, more important areas which I want to focus on first. Tux Commander could use complete rewrite to pure C, but that's fulltime work for several months. Volunteers are welcome of course. [...] Forgot to mention that I intentionally disabled PPC archs in the Fedora package. I can only support i386 and x86_64 at the moment. There should be some solution, but I do not know if it is really good to (temporarly) do in the next upload the restriction for Architecture to only little endian archs. Kind regards, and thanks for any further suggestions Salvatore signature.asc Description: Digital signature
How handle Architecture when package is restricted/limited to only some archs?
Hi tuxcmd is currently by upsteam restricted to the Architectures i386 and x86_64. [1]. As suggested in a previous thread I had put Architecture: any in the control file, and now I'm having the following situation: On powerpc all Build-Depends are satisfied, and also the package get's build, but tuxcmd will not work at all on this architecture. Are there any policy about that, if I should explicitely list only i386, amd64 and source there? I have not found a hint on that on policy 5.6.8, it says there that Specifying a list of architectures indicates that the source will build an architecture-dependent package, and will only work correctly on the listed architectures. So I assume I should switch to listing the supported archs? Thanks in advance Kind regards Salvatore [1] https://bugzilla.redhat.com/show_bug.cgi?id=449367 -- .-. oo| Debian GNU/Linux -- The power of freedom -- /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: How handle Architecture when package is restricted/limited to only some archs?
Hi Don Thanks for the fast reply. On Sun, Feb 01, 2009 at 11:51:08PM -0800, Don Armstrong wrote: On Mon, 02 Feb 2009, Salvatore Bonaccorso wrote: tuxcmd is currently by upsteam restricted to the Architectures i386 and x86_64. [1]. As suggested in a previous thread I had put Architecture: any in the control file, and now I'm having the following situation: On powerpc all Build-Depends are satisfied, and also the package get's build, but tuxcmd will not work at all on this architecture. Why not? There's nothing obvious about tuxcmd that makes it only suitable for i386 and amd64. If it doesn't work properly on archs other than i386 and amd64, that sounds like bugs that should be fixed (likely resulting from poor coding practices on the part of upstream.) Yes I see. If neither you nor upstream is able to resolve the bugs due to lack of access to powerpc architecture machines (or any of the other architectures that this package can build successfully on) I'd suggest talking to the powerpc porters (and other arch porters) for assistance. Indeed I currently have only access to i386 and amd64 machines and so I'm neither able to debug #513891. So I will contact upstream about that and the powerpc porters and ask if they could help. Thanks for your reply and kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: pidgin-osd
Hi Michael Note: I'm not a Debian Developer, so I cannot sponsor your package. Thanks for your work! On Sun, Jan 18, 2009 at 04:25:07PM +0100, Michael Domann wrote: Dear mentors, I am looking for a sponsor for my package pidgin-osd. * Package name: pidgin-osd Version : 0.1.0-1 Upstream Author :Maik Broemme * URL : https://babelize.org/pidgin-osd.php * License : GPL3 Section : net It builds these binary packages: pidgin-osd - osd plugin for pidgin The package appears to be lintian clean and builds fine in pbuilder. I noticed a small typo in the short description in debian/control: Description: osd plugim for pidgin should probably be osd plugin for pidgin. Maybe if you agree, you can also change the description to be: - Description: X On-Screen Display plugin for pidgin X On-Screen Display (OSD) plugin for pidgin . This is an application to print events on the X root screen on receiving incoming messages from pidgin. . It uses the xosd library to print various events on the X console. - But as said, this is only a side comment, I cannot upload your package not beeing a DD. Kind regards Salvatore -- .-. oo| Debian GNU/Linux -- The power of freedom -- /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: RFS: libabstract-ruby
Hi
First I'm not a DD! I looked only at your package, and hope I can give
you some feedback.
On Sat, Dec 20, 2008 at 12:04:27PM -0800, Bryan McLellan wrote:
Dear mentors,
I am looking for a sponsor for my package libabstract-ruby.
* Package name: libabstract-ruby
Version : 1.0.0-1
Upstream Author : Makoto Kuwata k...@kuwata-lab.com
* URL : http://rubyforge.org/projects/abstract
* License : Ruby's License
Section : libs
It builds these binary packages:
libabstract-ruby - A library which enables you to define abstract
method in Ruby.
libabstract-ruby-doc - Documentation for libabstract-ruby
libabstract-ruby1.8 - A library which enables you to define abstract
method in Ruby.
libabstract-ruby1.9 - A library which enables you to define abstract
method in Ruby.
The package appears to be lintian clean.
The upload would fix these bugs: 509284
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libabstract-ruby
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libabstract-ruby/libabstract-ruby_1.0.0-1.dsc
I noticed that you still use Standards-Version 3.6.2. If I'm right,
the current policy version is 3.8.0.1.
Here is the further lintian output on the package, done with
lintian -I libabstract*ch*
(note: you can check it with lintian -iI libabstract*ch* to have more
informative output):
I: libabstract-ruby source: debian-watch-file-is-missing
This is only informational, it's not required. But since the
download URL seems to be
http://rubyforge.org/frs/download.php/9171/abstract_1.0.0.tar.bz2
it should be not to bad to add a debian/watch file if possible.
W: libabstract-ruby source: debhelper-but-no-misc-depends libabstract-ruby
The help text of lintian says here:
N:The source package uses debhelper but it does not use ${misc:Depends} in
N:the given binary package's debian/control entry. This is required so the
N:dependencies are set correctly in case the result of a call to any of
N:the dh_ commands cause the package to depend on another package.
N:
N:Refer to the debhelper(7) manual page for details.
N:
N:Severity: normal; Certainty: certain
But I'm not sure here, hope you get a feedback from a Sponsor!
W: libabstract-ruby source: debhelper-but-no-misc-depends libabstract-ruby-doc
Seems to be the same as above.
W: libabstract-ruby source: ancient-standards-version 3.6.2 (current is 3.8.0)
I think you should use the most recent policy version for
Standards-Version, 3.6.2 is really old. But if the package is still
3.8.0 compliant, there is only need to change the version.
I: libabstract-ruby source: build-depends-without-arch-dep ruby-pkg-tools
I: libabstract-ruby source: build-depends-without-arch-dep graphviz
These two are not warnings, but only informational tags. But see the
help text about it, then you can decide if you should these into
Build-Depends-Indep.
W: libabstract-ruby1.8: description-synopsis-might-not-be-phrased-properly
W: libabstract-ruby1.9: description-synopsis-might-not-be-phrased-properly
W: libabstract-ruby: description-synopsis-might-not-be-phrased-properly
You can leave the . (dot) at the end of the phrase.
Kind regards
Salvatore
--
.-.
oo| Debian GNU/Linux -- The power of freedom --
/`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/
(\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394
signature.asc
Description: Digital signature
Problem with code duplication in my package tuxcmd-modules
Hi I have a problem to finalize my package tuxcmd-modules. First I had to make a repackaged upstream source due to it ships else non-free components, and further has some code duplication (e.g. ships own copy of bzip2, but want to use system one). Here I have a problem. The zip module in tuxcmd-modules uses zibarchive, which ships a own, but modified zlib directory which contains the source (e.g. zconf.h is different) for zlib. The package in his current shape is uploaded to mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd-modules/tuxcmd-modules_0.6.50+dfsg-1.dsc How can I handle bests this issue, do when possible prevent code dublication? Kind regards and thanks for your help Salvatore -- .-. Debian GNU/Linux -- The power of freedom -- oo| Salvatore Bonaccorso Email: salvatore.bonacco...@gmail.com /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: Problem with code duplication in my package tuxcmd-modules
Hi On Wed, Dec 17, 2008 at 12:17:21PM +0100, Salvatore Bonaccorso wrote: I have a problem to finalize my package tuxcmd-modules. First I had to make a repackaged upstream source due to it ships else non-free components, and further has some code duplication (e.g. ships own copy of bzip2, but want to use system one). Here I have a problem. The zip module in tuxcmd-modules uses zibarchive, which ships a own, but modified zlib directory which contains the source (e.g. zconf.h is different) for zlib. After some rechearch since ZipArchive uses a slightly modified zlib to fit it's need it seams not easy to use system zlib. Resource: http://www.artpol-software.com/ZipArchive/KB/0610050933.aspx Kind regards Salvatore -- .-. Debian GNU/Linux -- The power of freedom -- oo| Salvatore Bonaccorso Email: salvatore.bonacco...@gmail.com /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
copyrights of some files in source for tuxcmd-modules (handling non-free source parts).
Hi Currently I'm working on my package tuxcmd-modules, but I still have a problem with the debian/copyright. The sources for the modules I would package are here: http://prdownloads.sourceforge.net/tuxcmd/tuxcmd-modules-0.6.50.tar.bz2?download [I havent uploaded a version to mentors.debian.net since, it is not yet ready for first review. But if it's better I will upload the source package to m.d.n, even it is not yet really ready] Under unrar/unrar/* there are some files, they have no Copyright text, but for this files, there is a unrar/unrar/license.txt. Under unrar/unrar/* are located the sources for the nonfree version of unrar. I would simply proceed by removing the non-free parts from source tarball and repackage the sources. This means, providing GVFS, ZIP and libarchive plugin, but not the unrar plugin. Could you please give some feedback on this? Are there any suggestions on this? Thanks in advance and kind regards Salvatore -- .-. Debian GNU/Linux -- The power of freedom -- oo| Salvatore Bonaccorso Email: salvatore.bonacco...@gmail.com /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: copyrights of some files in source for tuxcmd-modules (handling non-free source parts).
Hi On Sat, Dec 13, 2008 at 11:25:53PM +0900, Paul Wise wrote: On Sat, Dec 13, 2008 at 10:18 PM, Salvatore Bonaccorso salvatore.bonacco...@gmail.com wrote: I would simply proceed by removing the non-free parts from source tarball and repackage the sources. And maybe ask upstream to distribute the non-free bits separately. Also ask them if it would be possible to just run the unrar program (already in Debian non-free) instead of duplicating the code. Yes will (try) to contact upstream about that. Could you please give some feedback on this? Are there any suggestions on this? Some info in the devref about repacking tarballs: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-origtargz Thanks for the hint. I added now a get-orig-source target to my debian/rules which will also unpack an upstream source and with a fix-orig-source target then perform the operation we need to get the repackaged upstream source. Kind regards Salvatore -- .-. Debian GNU/Linux -- The power of freedom -- oo| Salvatore Bonaccorso Email: salvatore.bonacco...@gmail.com /`'\ GPG key ID: 0x518DA394http://arda.homelinux.org/~salvi/ (\_;/) Fingerprint: 346C D422 1366 FA52 D898 5666 BD45 6753 518D A394 signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi On Tue, Dec 09, 2008 at 11:09:17PM +0100, Michal Čihař wrote: Dne Tue, 9 Dec 2008 22:16:31 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): [ questions about right handling of copyright file ] The wiki Proposal states The copyright statement SHOULD include copyright year(s) and the copyright holder's name (revision 413) So I'm still unsure about this point, but fixed the rest of the copyright file (in particular the translations files). Well, you should list all copyright statements as well in normal copyright file. In this case I'd stick with 2004-2008 (or whatever range matches all files). I reuploaded corrected version with copyright file again to mentors repository. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi I yust reuploaded package whith improvements done: On Mon, Dec 08, 2008 at 03:06:00PM +0100, Michal Čihař wrote: Dne Sun, 7 Dec 2008 19:25:47 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc Why is it only arch: i386 amd64? As you proposed in this subthread I changed the arch again back to any. Also debian/copyright lacks some information: - translation copyrights are not included - also some source files have more than one copyright holders Using http://wiki.debian.org/Proposals/CopyrightFormat might be also a good idea. I followed that, but have still some unsure points abaout that. Example: Files: * Copyright: Copyright 2008, Tomáš Bžatek [EMAIL PROTECTED] License: GPL-2+ On Debian systems the full text of the GNU General Public License can be found in the `/usr/share/common-licenses/GPL' file. Wiki-Proposal states, that for the copyright I should list all including years. Some of the files have different copyright years, so I need to really have for each such file an appropriate Section, even the License and Author is the same? Example: ./UChecksum.pas (Copyright 2004, by Tomas Bzatek), and ./UConfig.pas (Copyright 2008, by Tomas Bzatek). The wiki Proposal states The copyright statement SHOULD include copyright year(s) and the copyright holder's name (revision 413) So I'm still unsure about this point, but fixed the rest of the copyright file (in particular the translations files). Furthermore I tryied to improve the package description, to not confuse the reader about shiping in tuxcmd package the extension VFS modules, and add a note also in README.Debian that those comes with an additional package tuxcmd-modules. The tuxcmd-modules package is still not ready yet. Thanks again for checking and kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi On Tue, Dec 09, 2008 at 10:14:48AM +0100, Michal Čihař wrote: Dne Mon, 8 Dec 2008 22:29:15 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): Yes I have to rephrase these sentences. The reason about that is the following: upstream ships the base filemanager tuxcmd in a source tarball, and in another tarball some modules (the above claimed, and I should rephrase the description for tuxcmd itself). For the modules I filled an separate ITP (see http://bugs.debian.org/508082). The second I have to repackage the upstream tarball to remove the non free module parts (unrar and libarchive plugin). What's non-free on libarchive? It's already packaged in main. I guess same applies to unrar (there is free unrar, but there is no free rar). Ok will work on this. I simply was a bit confused about unrar/unrar/license.txt and some of the statements in libarchive/libarchive-2.5.5/COPYING. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi On Mon, Dec 08, 2008 at 03:06:00PM +0100, Michal Čihař wrote: Dne Sun, 7 Dec 2008 19:25:47 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc Why is it only arch: i386 amd64? Also debian/copyright lacks some information: - translation copyrights are not included - also some source files have more than one copyright holders Using http://wiki.debian.org/Proposals/CopyrightFormat might be also a good idea. I fix this issues when preparing to upload a new version to check, following the proposal, thanks! The reason I used only arch i386 and amd64, was bit stupid as I was not sure if the package would also build cleanly under the other architectures. See the note of the Author on: https://bugzilla.redhat.com/show_bug.cgi?id=449367 Description says Extendable via plugin system, several VFS modules available in the distribution, while README.Debian The tuxcmd currently does not provide the additional plugins provided also upstream, namely gnome_vfs, unrar_plugin and zip_plugin.. What is problem in actually providing plugins? Yes I have to rephrase these sentences. The reason about that is the following: upstream ships the base filemanager tuxcmd in a source tarball, and in another tarball some modules (the above claimed, and I should rephrase the description for tuxcmd itself). For the modules I filled an separate ITP (see http://bugs.debian.org/508082). The second I have to repackage the upstream tarball to remove the non free module parts (unrar and libarchive plugin). Then tuxcmd-modules will extend tuxcmd by these additional modules. This second package tuxcmd-modules I have not yet ready to upload to mentors.debian.net, which then will extend the functionality of tuxcmd if installed. So that is what I ment or wanted to say in the README.Debian, but I should do better. The tuxcmd package contains the base Tux Commander file manager. To extend the functionality using some VFS modules available you need to install the additional package tuxcmd-modules. Should explain the situation better. Since english is not my native language I should also post to the l10n-list, for checking the package description, for having best possible description. Is this a good approach to this? Or do you think it's still better to import also the free modules into the upstream source and repackage the tarball? I would upload a corrected package asap, and if ready since then, also the tuxcmd-modules package (if this is the right approach). Kind regards and thanks for checking Salvatore signature.asc Description: Digital signature
Re: RFS: tuxcmd
Hi On Mon, Dec 08, 2008 at 10:29:15PM +0100, Salvatore Bonaccorso wrote: On Mon, Dec 08, 2008 at 03:06:00PM +0100, Michal Čihař wrote: Dne Sun, 7 Dec 2008 19:25:47 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc Why is it only arch: i386 amd64? Also debian/copyright lacks some information: - translation copyrights are not included - also some source files have more than one copyright holders [...] I fix this issues when preparing to upload a new version to check, following the proposal, thanks! The reason I used only arch i386 and amd64, was bit stupid as I was not sure if the package would also build cleanly under the other architectures. See the note of the Author on: https://bugzilla.redhat.com/show_bug.cgi?id=449367 Only a further note on this. tuxcmd uses some parts, which is not available on all architectures. fp-compiler is only available for amd64, arm, i386, powerpc and sparc. How should I handle this correctly? GTK+ 2 units in same way also only for the above archs. Extend arch also for those archs and then try if tuxcmd will compile also under those architectures? Kind regards Salvatore signature.asc Description: Digital signature
RFS: tuxcmd
Dear mentors, I am looking for a sponsor for my package tuxcmd. * Package name: tuxcmd Version : 0.6.50-1 Upstream Author : Tomáš Bžatek [EMAIL PROTECTED] * URL : http://tuxcmd.sourceforge.net * License : GPL Section : utils It builds these binary packages: tuxcmd - twin-panel (commander-style) file manager using GTK2 The package appears to be lintian clean. The upload would fix these bugs: 498513 Could please someone check this package? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tuxcmd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tuxcmd/tuxcmd_0.6.50-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
Re: RFS: giplet
Hi Thanks for yours hints Michal Čihař! I reuploaded the package with the modifications done. dget http://mentors.debian.net/debian/pool/main/g/giplet/giplet_0.1.7-1.dsc On Wed, Dec 03, 2008 at 03:04:05PM +0100, Michal Čihař wrote: Dne Mon, 1 Dec 2008 09:52:52 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): - dget http://mentors.debian.net/debian/pool/main/g/giplet/giplet_0.1.7-1.dsc - You miss debian/README.source. Sorry about that. Checking 4.14, is it enough to simply state that the package used dpatch to manage modifications to the source and then link to /usr/share/doc/dpatch/README.source.gz? In the current uploaded version I prefred to state there the full text instead to only refer to the README.source.gz. I copied this text from /usr/share/doc/dpatch/README.source.gz as template. It describes the steps required by 4.14. - please remove comments from many files in debian/, that they are examples. Ok! I removed all comment lines from debian/watch and also from debian/rules. But second I then followed your suggestion to use dh commands and adding dpatch hooks (used /usr/share/doc/debhelper/examples/rules.simple). - Are you sure package needs python-gtk2-dev for building? As it does not contain single line of C code, I doubt it really needs it. The configure script of giplet checks for pygtk-2.0 but for building python-gtk2-dev is not required (only python-gtk2 dependency then for the applet itself). I added a new patch removing the PYGTK test in the configure script. If yes, I should ask also to the upstream author. (02_do_not_check_for_pygtk.dpatch). Thanks for checking the package. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: giplet
Hi On Thu, Dec 04, 2008 at 11:46:12AM +0100, Michal Čihař wrote: Hi Dne Thu, 4 Dec 2008 11:35:02 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): The configure script of giplet checks for pygtk-2.0 but for building python-gtk2-dev is not required (only python-gtk2 dependency then for the applet itself). I added a new patch removing the PYGTK test in the configure script. If yes, I should ask also to the upstream author. (02_do_not_check_for_pygtk.dpatch). Well in this case I'd probably leave the build dependency as is for now, just try to persuade upstream whether they can not change the check for just existence of gtk module. Ok. reverted the changes about the 02_do_not_check_for_pygtk.dpatch. I will contact upstream author regarding this check. I reuploaded the package without these changes. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: giplet
Hi On Thu, Dec 04, 2008 at 12:18:01PM +0100, Michal Čihař wrote: Dne Thu, 4 Dec 2008 12:07:22 +0100 Salvatore Bonaccorso [EMAIL PROTECTED] napsal(a): Ok. reverted the changes about the 02_do_not_check_for_pygtk.dpatch. I will contact upstream author regarding this check. I reuploaded the package without these changes. Uploaded, when you will want to upload next version contact me. You can find some hints here: http://people.debian.org/~nijel/sponsoring/ (notably use [sponsoring] somewhere in subject). Thanks a lot for sponsoring and uploading this package. Have a nice day and kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: giplet
Dear mentors, On Mon, Dec 01, 2008 at 09:52:52AM +0100, Salvatore Bonaccorso wrote: Dear mentors, I am looking for a sponsor for my package giplet. * Package name: giplet Version : 0.1.7-1 Upstream Author : Erik Larson [EMAIL PROTECTED] * URL : http://giplet.sourceforge.net/ * License : GPL Section : gnome It builds these binary packages: giplet - GNOME IP display applet The package appears to be lintian clean. It also builds in a sid chroot with pbuilder (with pdebuild). The upload would fix these bugs: 426837 I uploaded the package again, now fixing also 4 Informational tags warnings, which I missed (empty dirs, and copyright listing of authors, and a package listed in Build-Deps which should not be there, but in the architecture independent part). It's still on the -1 version. Should I better increase the Debian version even if it wasn't uploaded and I fixed only this 4 informational tags warnings? Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
RFS: giplet
Dear mentors, I am looking for a sponsor for my package giplet. * Package name: giplet Version : 0.1.7-1 Upstream Author : Erik Larson [EMAIL PROTECTED] * URL : http://giplet.sourceforge.net/ * License : GPL Section : gnome It builds these binary packages: giplet - GNOME IP display applet The package appears to be lintian clean. It also builds in a sid chroot with pbuilder (with pdebuild). The upload would fix these bugs: 426837 Long description of the package is: Giplet is a simple GNOME panel applet that displays your computer's ip address. Giplet can either display the ip address of a specified ethernet interface or the ip address the outside world sees. . Giplet can also be set to recheck every so often in case your router resets or the ip address is renewed. Previous work on this package was done by David Paleino [EMAIL PROTECTED], but talked with him via private email. He packaged up to 0.1.3 and uploaded it to mentors. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/giplet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/giplet/giplet_0.1.7-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
RFS: inkscape-textext
Dear mentors, I am looking for a sponsor for my package inkscape-textext. * Package name: inkscape-textext Version : 0.4.4-1 * Upstream Author : Pauli Virtanen [EMAIL PROTECTED] * URL : http://www.elisanet.fi/ptvirtan/software/textext/ * License : BSD Section : graphics It builds these binary packages: inkscape-textext - Inkscape extension for editable LaTeX text or formula The package appears to be lintian clean. The upload would fix these bugs: 500777 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/inkscape-textext - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_0.4.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
Re: RFS: inkscape-textext
Dear Luca On Sat, Nov 29, 2008 at 03:18:43PM +0100, Luca Bruno wrote: Salvatore Bonaccorso scrisse: Dear mentors, I am looking for a sponsor for my package inkscape-textext. inkscape-textext - Inkscape extension for editable LaTeX text or formula I'm not really in favor of this ITP, as it mainly seems as a wring reaction to the latex extension not working properly. Many thanks for your reaction on this! Indeed yes, you are right, it was a porbably to fast reaction. I will so the sponsoring request on mentors.debian.net again. First, before I also answer to your other paragraphs: do you think, there is a change that the patch found in launchpad bugtracker (See Bugreport #506285) can go into the inkscape package? This will render back again the LaTeX formula rendering for 0.46 again. It would be really great to have this working again, out of the box. All main inkscape extensions are maintained within the upstream repo as the extension interface is used to change a lot between each release, and so they could broke often. You should talk to textext upstream to better integrate with inkscape upstream. Thanks for the suggestion! I will try to drop an email to the textext upstream autor if this is possible! I definitely would not welcome a one-package-per-extension policy, that is the field where your package is currently going. I have again cancelled now my request on mentors.debian.net about this. Sorry about that. Thus I'm suggesting you to drop this ITP, work with Wolfram (which currently seems a bit busy) to fix the other two related bugs, suggest your upstream to get in touch with Inkscape developers to integrate the extension avoiding duplicate code and maybe start discussing a better extensions packaging (which would be really appreciate, IMHO). Ok I will try to again reach Wolfram via BTS, as found in 506285 there is a patch to have at least in 0.46 the exporting (but without reediting) formula again working, but I haven't get a reply from Wolfram about this. Many thanks again for your work and for your reply. Hope my english is understandable. Kind regards Salvatore signature.asc Description: Digital signature
