RFS: otcl (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.13-1 of my package otcl. It builds these binary packages: libotcl1 - an extension to Tcl/Tk for object-oriented programming libotcl1-dev - an extension to Tcl/Tk for object-oriented programming otcl-shells - an extension to Tcl/Tk for object-oriented programming The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/otcl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/otcl/otcl_1.13-1.dsc I would be glad if someone uploaded this package for me. Kind regards YunQiang Su -- 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/w2j17e2b7571004010002l847ea636k91c29d2b4202f...@mail.gmail.com
RFS: cryptkeeper (updated package)
Hi, my usual sponsor for cryptkeeper is busy in this period, so I'm asking here if someone could sponsor the upload... It's a new upstream release only minor changes. The only important change is the DM-upload flag. It builds these binary packages: cryptkeeper - EncFS system tray applet for GNOME The package appears to be lintian clean. The upload would fix these bugs: 554291 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cryptkeeper - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cryptkeeper/cryptkeeper_0.9.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Francesco Namuri -- 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/9a09fbecf676eaa42b37de2fe0dc4f4c.squir...@hal.hierax.net
Re: RFS: cryptkeeper (updated package)
On Thu, Apr 01, 2010 at 11:07:23AM +0200, Francesco Namuri wrote: Hi, my usual sponsor for cryptkeeper is busy in this period, so I'm asking here if someone could sponsor the upload... The only important change is the DM-upload flag. Don't you think this exact part is best kept for someone knowing you and the package? Do you expect your sponsor to be away for a longer period of time? Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0xD49AE731 \ /Campaign : CaCert Assurer X against HTML : Debian Developer / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ signature.asc Description: Digital signature
Re: RFS: coffeescript
On Wed, Mar 31, 2010 at 10:44:20PM -0400, Geza Kovacs wrote: (Please CC any replies to me) Dear mentors, I am looking for a sponsor for my package coffeescript. It builds these binary packages: coffeescript - interpreter and compiler for the CoffeeScript language coffeescript-doc - documentation for coffeescript Quoting Upstream Website: Disclaimer: CoffeeScript is just for fun. Until it reaches 1.0, there are no guarantees that the syntax won't change between versions. That said, it compiles into clean JavaScript (the good parts) that can use existing JavaScript libraries seamlessly, and passes through JSLint without warnings. The compiled output is quite readable — pretty-printed, with comments preserved intact. Do you think it's sensible to have that packaged in debian (and it's stable releases)? Looks rather like a volatile thing where one wants for a 1.0 before packaging to me (though that impressin is based on a quick look on the webpage so you may know better ;)) Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0xD49AE731 \ /Campaign : CaCert Assurer X against HTML : Debian Developer / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ signature.asc Description: Digital signature
A meager copyright. Remotely acceptable?
Dear mentors, I probably prematurely responded to an RFP for 'oftpd', an FTP server for only anonymous access, and only giving read access. The RFP reportee himself suggested GPL as the applicable license, which I now see is utterly nonsense. I could use the insights of those better understanding these matters. The only mention of GPL in the entire source archive are found in two specifications for building RPM-packages. Beyond that, the files produced using autotools contain the usual FSF attribution. That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a claim of copyright. The text is below reproduced verbatim. As far as I can understand the text there seems to yield no possiblility to relate this to GPL, and to no other DFSG-compliant license either. Am I correct in this observation? Best regards Mats Erik Andersson, fil. dr # oftpd-0.3.7/COPYINGbegins Copyright 2000, 2001 Shane Kerr. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # oftpd-0.3.7/COPYINGends -- 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/20100401123756.ga4...@mea.homelinux.org
Re: A meager copyright. Remotely acceptable?
On Thu, Apr 1, 2010 at 8:37 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a claim of copyright. The text is below reproduced verbatim. As far as I can understand the text there seems to yield no possiblility to relate this to GPL, and to no other DFSG-compliant license either. Am I correct in this observation? That looks like a BSD-like license to me. It seems to satisfy the DFSG too: http://www.debian.org/social_contract#guidelines It is a good idea to read the SC DFSG and attempt to apply the DFSG item by item to the license. -- 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 Archive: http://lists.debian.org/y2ie13a36b31004010537g9c694581p6ae2b2a3be4cb...@mail.gmail.com
RFS: libphp-swiftmailer
Dear mentors, I am looking for a sponsor for my package libphp-swiftmailer. * Package namenbsp;nbsp;nbsp; : libphp-swiftmailer nbsp; Versionnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; : 4.0.6-1 nbsp; Upstream Author : 2004-2009 Chris Corbyn lt;ch...@w3style.co.ukgt; * URLnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; : http://swiftmailer.org/ * Licensenbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; : LGPL nbsp; Sectionnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; : php It builds these binary packages: libphp-swiftmailer - component-based library for sending e-mails The package appears to be lintian clean. The upload would fix these bugs: 576088 My motivation for maintaining this package is: I'm involved in a group who manage to package symfony1.4 for debian. I like symfony and libraries used. I knew and used Swift Mailer for many years and I follow its development closely. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libphp-swiftmailer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libphp-swiftmailer/libphp-swiftmailer_4.0.6-1.dsc I would be glad if someone uploaded this package for me. Kind regards Nicolas Roudaire signature.asc Description: OpenPGP digital signature
Re: RFS: coffeescript
On 04/01/2010 06:03 AM, Christoph Egger wrote: Quoting Upstream Website: Disclaimer: CoffeeScript is just for fun. Until it reaches 1.0, there are no guarantees that the syntax won't change between versions. That said, it compiles into clean JavaScript (the good parts) that can use existing JavaScript libraries seamlessly, and passes through JSLint without warnings. The compiled output is quite readable — pretty-printed, with comments preserved intact. Do you think it's sensible to have that packaged in debian (and it's stable releases)? Looks rather like a volatile thing where one wants for a 1.0 before packaging to me (though that impressin is based on a quick look on the webpage so you may know better ;)) I'd agree with your worries if this were a purely interpreted language like Python, where changes in the interpreter require entire program rewrites so that existing deployments can still run. However, this is a compiled language, which outputs to standard Javascript. Hence, even in the unlikely case that a huge change makes existing programs uncompilable (I say unlikely because coffeescript has done a good job of maintaining backwards compatibility with releases), then the existing compiled Javascript that has been deployed will still work. Since this is primarily used for short-term web development, and not huge multi-year projects, then the question of whether a program will still compile years later is less of an issue. Also note that Debian is already ripe with languages which haven't yet reached 1.0 and are still adding new syntactic features, like boo. I believe so long as there aren't Debian packages that depend on coffeescript to get compiled, the availability of this package shouldn't cause additional maintainability issues, and as with any cutting-edge development tools, it should be left up to the user whether to use them or not. -- 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/4bb4aa73.7020...@mit.edu
Re: A meager copyright. Remotely acceptable?
Hi, Mats: On Thursday 01 April 2010 14:37:56 Mats Erik Andersson wrote: Dear mentors, I probably prematurely responded to an RFP for 'oftpd', an FTP server for only anonymous access, and only giving read access. The RFP reportee himself suggested GPL as the applicable license, which I now see is utterly nonsense. I could use the insights of those better understanding these matters. The only mention of GPL in the entire source archive are found in two specifications for building RPM-packages. Beyond that, the files produced using autotools contain the usual FSF attribution. That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a claim of copyright. The text is below reproduced verbatim. As far as I can understand the text there seems to yield no possiblility to relate this to GPL, and to no other DFSG-compliant license either. Am I correct in this observation? The COPYING file obviously states the intention for a BSD-like license. On the other hand, GPL on the RPM-build files is not incompatible with that but that leaves the question about all the other source files. As long as the author of the COPYING file retains copyright for the whole lot (i.e. has not copied anything from other sources), I think the best path would be approach the upstream maintainer and ask him to clarify the situation of the other copyrigth files. You can even go for the extra mile, once the author's position is made clear to offer to patch yourself the files (after all, the only thing it would be needed is adding a boilerplate header to all of them). Without this (IMHO) standard copyright laws are in effect which means you can't even touch the non-stated files with a ten foot pole. -- 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/201004011706.35941.jesus.nava...@undominio.net
Re: A meager copyright. Remotely acceptable?
The situation is getting clearer! torsdag den 1 april 2010 klockan 20:37 skrev Paul Wise detta: On Thu, Apr 1, 2010 at 8:37 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a claim of copyright. The text is below reproduced verbatim. As far as I can understand the text there seems to yield no possiblility to relate this to GPL, and to no other DFSG-compliant license either. Am I correct in this observation? That looks like a BSD-like license to me. It seems to satisfy the DFSG too: A comparison with the other BSD licenses, shows that the present license is nothing else than the 2-clause BSD license, Simplified BSD License, or FreeBSD License as is explained to me in http://en.wikipedia.org/wiki/BSD_licenses According to the same page it is therefore DFSG compatible. Thus the only question for me seems to be how to name this license in a DEP-5 formed copyright file, a file which I will have to compile. In the directory '/usr/share/common-licenses/' only the 3-clause BSD license, New BSD License, is present. Gleaning in the package 'openntpd', I find that License: BSD-2 and inclusion of the test from COPYING would be the thing to do. Does anyone disagree with this resolution? -- Mats Erik Andersson Abbonerar på: debian-mentors, debian-devel-games, debian-perl, debian-ipv6 -- 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/20100401154038.ga6...@mea.homelinux.org
Re: A meager copyright. Remotely acceptable?
A clarification on GPL and contributions. torsdag den 1 april 2010 klockan 17:06 skrev Jesús M. Navarro detta: Hi, Mats: On Thursday 01 April 2010 14:37:56 Mats Erik Andersson wrote: Dear mentors, The RFP reportee himself suggested GPL as the applicable license, which I now see is utterly nonsense. I could use the insights of those better understanding these matters. The only mention of GPL in the entire source archive are found in two specifications for building RPM-packages. Beyond that, the files produced using autotools contain the usual FSF attribution. The COPYING file obviously states the intention for a BSD-like license. On the other hand, GPL on the RPM-build files is not incompatible with that but that leaves the question about all the other source files. As long as the The two GPL-licensed specifications were contributed by other people. Apart from the files generated by the autotools suite, I find no other explicit mention of contributed text in the source code itself. There are in AUTHORS named persons with pointers to functionality they improved, but apart from a single mention of a single individual in a single C-source file, the code additions are anonymous. author of the COPYING file retains copyright for the whole lot (i.e. has not copied anything from other sources), I think the best path would be approach the upstream maintainer and ask him to clarify the situation of the other copyrigth files. You can even go for the extra mile, once the author's position is made clear to offer to patch yourself the files (after all, the only thing it would be needed is adding a boilerplate header to all of them). Without this (IMHO) standard copyright laws are in effect which means you can't even touch the non-stated files with a ten foot pole. Do you mean that I am not allowed to patch (using source format 3.0-quilt) any of the code? At this time I know one compiler warning and some dubious IPv6-code that I probably would like to fix. The BSD-clause in COPYING allows modifications, so I do not understand how I should interpret the ten foot pole. Please, tell me! Mats Erik Andersson -- 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/20100401161348.ga6...@mea.homelinux.org
Re: RFS: coffeescript
Hi! On Thu, Apr 01, 2010 at 10:15:15AM -0400, Geza Kovacs wrote: On 04/01/2010 06:03 AM, Christoph Egger wrote: Quoting Upstream Website: Disclaimer: CoffeeScript is just for fun. Until it reaches 1.0, there are no guarantees that the syntax won't change between versions. That said, it compiles into clean JavaScript (the good parts) that can use existing JavaScript libraries seamlessly, and passes through JSLint without warnings. The compiled output is quite readable — pretty-printed, with comments preserved intact. Do you think it's sensible to have that packaged in debian (and it's stable releases)? Looks rather like a volatile thing where one wants for a 1.0 before packaging to me (though that impressin is based on a quick look on the webpage so you may know better ;)) I'd agree with your worries if this were a purely interpreted language like Python, where changes in the interpreter require entire program rewrites so that existing deployments can still run. However, this is a compiled language, which outputs to standard Javascript. Hence, even in the unlikely case that a huge change makes existing programs uncompilable (I say unlikely because coffeescript has done a good job of maintaining backwards compatibility with releases), then the existing compiled Javascript that has been deployed will still work. Since this is primarily used for short-term web development, and not huge multi-year projects, then the question of whether a program will still compile years later is less of an issue. Also note that Debian is already ripe with languages which haven't yet reached 1.0 and are still adding new syntactic features, like boo. I believe so long as there aren't Debian packages that depend on coffeescript to get compiled, the availability of this package shouldn't cause additional maintainability issues, and as with any cutting-edge development tools, it should be left up to the user whether to use them or not. OK fair enough. Actually the language looks quite interesting so I'm giving it a look right now. * Could you maybe merge the changelog entries into a single one? There's no reason to increase the debian revision for every bullet-point ;) * You're using format '3.0 (quilt)' for your package so applying the patches works at extraction time and there's no need for a '--with quilt' in the rules file (also, for a --with quilt you'd need to build-depend on a correct version of the quilt package) * Your patches don't have any description on them. I've missed such information quite often when adopting some package (there's some DEP for a uniform format somewhere). Also have you forwarded the patches upstream? Have you tested your package with lintian? I'm certainly not nit-picking on Information or Pedantic tags but some of the Error/Warnings definitely look worth fixing (invoking linitan with -i additionally gives a description of the issues at hand): /--- % lintian -IE --pedantic /var/cache/pbuilder/result/coffeescript_0.5.6-6_i386.changes I: coffeescript source: quilt-patch-missing-description fix-node-is-nodejs.patch I: coffeescript source: quilt-patch-missing-description install-to-lib-coffeescript.patch E: coffeescript source: missing-build-dependency quilt (= 0.46-7~) W: coffeescript source: out-of-date-standards-version 3.8.1 (current is 3.8.4) P: coffeescript-doc: no-upstream-changelog I: coffeescript-doc: extended-description-is-probably-too-short W: coffeescript-doc: wrong-section-according-to-package-name coffeescript-doc = doc I: coffeescript-doc: possible-documentation-but-no-doc-base-registration P: coffeescript: no-upstream-changelog W: coffeescript: manpage-has-useless-whatis-entry usr/share/man/man1/coffee.1.gz W: coffeescript: binary-without-manpage usr/bin/cake W: coffeescript: doc-base-unknown-section coffeescript:5 Development E: coffeescript: doc-base-file-references-missing-file coffeescript:8 /usr/share/doc/coffeescript/html/coffee-script.html E: coffeescript: doc-base-file-references-missing-file coffeescript:9 /usr/share/doc/coffeescript/html/*.html W: coffeescript: unusual-interpreter ./usr/bin/cake #!nodejs W: coffeescript: unusual-interpreter ./usr/bin/coffee #!nodejs W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/optparse.js W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/cake.js W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/parser.js \--- Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0xD49AE731 \ /Campaign : CaCert Assurer X against HTML : Debian Maintainer / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ signature.asc Description: Digital signature
Re: A meager copyright. Remotely acceptable?
On Thu, Apr 01, 2010 at 02:37:56PM +0200, Mats Erik Andersson wrote:
[...]
That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a
claim of copyright. The text is below reproduced verbatim. As far
as I can understand the text there seems to yield no possiblility to
relate this to GPL, and to no other DFSG-compliant license either.
Am I correct in this observation?
[...]
That's the 2-Clause BSD license:
http://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29
I used to use it for my projects before I switched them to the ISC
license (functionally the same but with more terse wording). It is
both DFSG-free and GPL-compatable, FWIW.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
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/20100401195434.gw1...@yuggoth.org
Re: A meager copyright. Remotely acceptable?
Jesús M. Navarro jesus.nava...@undominio.net writes: The COPYING file obviously states the intention for a BSD-like license. On the other hand, GPL on the RPM-build files is not incompatible with that but that leaves the question about all the other source files. As long as the author of the COPYING file retains copyright for the whole lot (i.e. has not copied anything from other sources), I think the best path would be approach the upstream maintainer and ask him to clarify the situation of the other copyrigth files. You can even go for the extra mile, once the author's position is made clear to offer to patch yourself the files (after all, the only thing it would be needed is adding a boilerplate header to all of them). Without this (IMHO) standard copyright laws are in effect which means you can't even touch the non-stated files with a ten foot pole. A lot of upstream authors think that repeating a boilerplate header in every file clutters their code and are uninterested in adding it, and are going to look at you in askance if you try to convince them that adding a clear license file to the source isn't sufficient to state the license for the entire source. And in practice, I suspect they're right. I'm one of those people who finds constantly repeating the license in every source file to be obnoxious, but to satisfy the desires of people who seem to feel that's necessary, I add a one-line statement pointing to the LICENSE file in every source file instead. To respond to the original poster, I think that distribution is clearly covered by the license and copyright in the COPYING file and wouldn't give it a second thought, although of course double-checking with upstream can't hurt I suppose. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874ojunaos@windlord.stanford.edu
RFS: task-spooler
Dear mentors, I am looking for a sponsor for my package task-spooler. * Package name: task-spooler Version : 0.6.6-2 Upstream Author : Lluís Batlle i Rossel vi...@vicerveza.homeunix.net * URL : http://vicerveza.homeunix.net/~viric/soft/ts/ * License : GPLv2+ Section : misc It builds these binary packages: task-spooler - personal job scheduler The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/task-spooler - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.6.6-2.dsc I would be glad if someone uploaded this package for me. Kind regards Alexander Inyukhin -- 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/20100401210926.ga10...@shurick.s2s.msu.ru
Re: RFS: windowlab (updated package)
Hi, Christoph Egger christ...@debian.org (28/03/2010): I get the impression that S. Engelsman took the function interruptibleXNextEvent() from Mark J. Kilgard's contribution to Blender, and then Engelsman wrote the replacing call instead of XNextEvent(). So this patch is part of Debian's blender package? might be, but as upstream code, not as a Debian-specific patch. FWIW and AFAICT, Blender code is usually just GPL'd and copyright gets assigned to the Blender Foundation (see copyright notices, with contributors listed thereafter). Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: coffeescript
Christoph Egger christ...@debian.org (01/04/2010): Do you think it's sensible to have that packaged in debian (and it's stable releases)? That's a question (but the other one can be replied to with a dummy RC bug prevening migration until it's in shape for a stable release, should the instability be only temporary). Mraw, KiBi. signature.asc Description: Digital signature
Re: A meager copyright. Remotely acceptable?
Mats Erik Andersson mats.anders...@gisladisker.se (01/04/2010): I probably prematurely responded to an RFP for 'oftpd', an FTP server for only anonymous access, and only giving read access. Another questions comes to mind: do we need this package? I'd hope several of which we already have can be trivially configured in this way? Maybe opening wishlist (documentation) bugs with appropriate procedure to do so would satisfy the original need? Mraw, KiBi. signature.asc Description: Digital signature
correctly upgrading a package's source format to 3.0(quilt)
Hi there, this is about a binary-indep package where there used to be lots of hacks in the build and other custom targets of debian/rules. One of the things that worry me most is that copying/moving files and applying patches in the build target is not acceptable (I believe). Especially, applying patches. The problem here is: I would like to create a copy of an upstream file and modify it. For that I: - backup the original - patch the original - move the patched original to where the modified copy should go - restore the original Now you agree that if I get hit by the bus and someone else has to take over... well not sure if they too wouldn't be looking for the next bus (or train, for that matter)... Other actions are: - extracting zip files to be included in the package - (re)moving unnecessary docs using 'find' - changing permissions - ... What would be the correct way to go about this? Surely, not everything can be done using quilt... and even if some actions were possible like removing the unnecessary docs (why bother and do this via patches that have to be recreated each time upstream changes something). Probably I need to carry out these actions using the patch target and let the user/developer know via README.source? But even then, what I described above is still not feasible. Regards, JM -- 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/4bb515f6.8030...@iip.lu
Re: A meager copyright. Remotely acceptable?
Cyril Brulebois k...@debian.org writes: Mats Erik Andersson mats.anders...@gisladisker.se (01/04/2010): I probably prematurely responded to an RFP for 'oftpd', an FTP server for only anonymous access, and only giving read access. Another questions comes to mind: do we need this package? I'd hope several of which we already have can be trivially configured in this way? Maybe opening wishlist (documentation) bugs with appropriate procedure to do so would satisfy the original need? vsftpd in particular does a very good job at this task. It's capable of doing more, but it has standard configuration options to limit it to only this mode and seems to be designed with a lot of security in mind. I've been using it for years with no complaints. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87aatmdbpp@windlord.stanford.edu
RFS: hivex
Dear mentors, I am looking for a sponsor for my package hivex. * Package name: hivex Version : 1.2.1-1 Upstream Author : Richard W.M. Jones rjo...@redhat.com * URL : http://libguestfs.org/ * License : LGPL 2.1 Section : utils It builds these binary packages: hivex - Tools for reading and writing Windows Registry hive files libhivex - Tools for reading and writing Windows Registry hive files libhivex-dev - Tools for reading and writing Windows Registry hive files libhivex-ocaml - Tools for reading and writing Windows Registry hive files libhivex-perl - Tools for reading and writing Windows Registry hive files The package appears to be lintian clean. My motivation for maintaining this package is: The library and tools provide a useful facility for os-probe tools to accurately determine the name of the default boot entry in Windows partitions of dual+ boot PCs that can be used by GRUB to correctly name boot entries. The library and tools can also be used by Linux-based diagnostic/repair/configuration tools for Wine and native Windows installations in virtual machine images or on bare hardware. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/h/hivex - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/h/hivex/hivex_1.2.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards TJ -- 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/1270169894.2595.19.ca...@hephaestion
RFS: drpython (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:3.11.1-2 of my package drpython. It builds these binary packages: drpython - simple and customizable editor for the Python language The package appears to be lintian clean. The upload would fix these bugs: 575845 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/drpython - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/drpython/drpython_3.11.1-2.dsc I would be glad if someone uploaded this package for me. Kind regards William Vera -- William Vera bi...@billy.com.mx PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- 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/s2zb3e93d821004011935sf9bad3d5z216f3c1c3f2e5...@mail.gmail.com
Re: A meager copyright. Remotely acceptable?
Le Thu, Apr 01, 2010 at 05:40:38PM +0200, Mats Erik Andersson a écrit : Thus the only question for me seems to be how to name this license in a DEP-5 formed copyright file, a file which I will have to compile. In the directory '/usr/share/common-licenses/' only the 3-clause BSD license, New BSD License, is present. Gleaning in the package 'openntpd', I find that License: BSD-2 and inclusion of the test from COPYING would be the thing to do. Does anyone disagree with this resolution? Dear Mats, the answer will depend on what level of precision is expected from the DEP-5 format. “Two clauses BSD” licenses often have a different disclaimer, so it may be needed to give them a separate name, according to how we will utilise DEP-5 license and copyright summaries. (In that case, an extention of the syntax to signal that they belong to a family of very similar licenses would be useful). This is why there is currently no “BSD-2” short name in the DEP-5 draft, only FreeBSD and NetBSD short names. Note also that this is work in progress, and that many things can change in the future. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100402024226.gb21...@kunpuu.plessy.org
Re: RFS: coffeescript
On 04/01/2010 12:42 PM, Christoph Egger wrote: * Could you maybe merge the changelog entries into a single one? There's no reason to increase the debian revision for every bullet-point ;) Done, I've merged the changelogs and am now back at 0.5.6-1 * You're using format '3.0 (quilt)' for your package so applying the patches works at extraction time and there's no need for a '--with quilt' in the rules file (also, for a --with quilt you'd need to build-depend on a correct version of the quilt package) Done, I've removed the --with-quilt * Your patches don't have any description on them. I've missed such information quite often when adopting some package (there's some DEP for a uniform format somewhere). Also have you forwarded the patches upstream? I've added descriptions to the patches, as recommended by DEP-3. I'm not forwarding the patches upstream, as they mostly relate to debian-specific quirks and are not generally useful (specifically, one deals with Node.js being installed to /usr/bin/nodejs in Debian instead of upstream's default location at /usr/bin/node, and the other is simply to allow coffee to be installed directly in /usr/bin/coffee instead of /usr/lib/coffeescript/coffee, whereas upstream instead uses an unnecessary symlink). Have you tested your package with lintian? I'm certainly not nit-picking on Information or Pedantic tags but some of the Error/Warnings definitely look worth fixing (invoking linitan with -i additionally gives a description of the issues at hand): I've fixed as many of the warnings as I could; currently the output of lintian is: P: coffeescript-doc: no-upstream-changelog I: coffeescript-doc: extended-description-is-probably-too-short P: coffeescript: no-upstream-changelog W: coffeescript: binary-without-manpage usr/bin/cake W: coffeescript: unusual-interpreter ./usr/bin/cake #!nodejs W: coffeescript: unusual-interpreter ./usr/bin/coffee #!nodejs W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/optparse.js W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/cake.js W: coffeescript: executable-not-elf-or-script ./usr/lib/coffeescript/parser.js The unusual-interpreter errors are of course unfixable since the program only runs on nodejs, there is no upstream changelog file (though there is one on the website, I could copy-paste it if desired but I don't think that's in line with Debian policy), and the warnings about executable permissions I unfortunately didn't figure out how to fix since quilt doesn't seem to be able to keep track of file permissions (if anyone has suggestions on how to store changes to the file permissions in the quilt patch set do let me know). Thanks, Geza -- 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/4bb55cfa.5020...@mit.edu
Re: correctly upgrading a package's source format to 3.0(quilt)
Without having more details, I'm thinking you need to work with upstream to make their source code more useful out of the box. -- 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 Archive: http://lists.debian.org/i2xe13a36b31004012026w805fdfddhb8963bf0e017d...@mail.gmail.com
Advice needed on splitting a package
Hi, This was originally posted on the debian-python[0] list, but I haven't heard anything so I hope no-one minds if I repost my question here. I'd appreciate some advice (where to start, what docs to read, etc) on building separate binary packages for RabbitVCS. Previously we just separated the upstream tarball itself, but that ended in tears. Now we have a single tarball and I'd like to split out the binary packages. You can check the tarball[1], but basically the top level structure is: [clients] - separate extension modules for nautilus, thunar, gedit and CLI [rabbitvcs] - the actual python module setup.py - the distutils based setup script **for the module, not the clients** (and a bunch of other maintenance stuff) Now, the module can be built with a really simple CBDS rules file[2]. The clients can be made with a dh_install debhelper rules file[3] that just move the files to where they need to be. But I'm a bit stuck on how to put it all together. Can anyone point me to some up-to-date docs, or maybe even a good package that's an example of what I'd like to do? Please CC me on replies :) Cheers, Jason Heeris [0] http://lists.debian.org/debian-python/2010/03/msg00033.html [1] http://code.google.com/p/rabbitvcs/downloads/detail?name=rabbitvcs-0.13.1.tar.gz [2] http://code.google.com/p/rabbitvcs/source/browse/tags/v0.13.1/packages/core/debian/rules [3] http://code.google.com/p/rabbitvcs/source/browse/tags/v0.13.1/packages/nautilus/debian/rules -- 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/t2hd69956981004012029qbd9bb75dx6f7dfbb5517f...@mail.gmail.com
Re: RFS: hivex
A review of your package:
copyright-questions.txt and ubuntu-bug-report-needs-packaging.txt
probably aren't needed in the source package
Why do you override the maintainer-not-full-name lintian complaint?
Please send the patches upstream. If you've already done that, please
document that using DEP-3:
http://dep.debian.net/deps/dep3/
4 of the lines in debian/watch are unnessecary and can be removed.
You are using dpkg-source v3 but still include simple-patchsys.mk from
cdbs, please drop that.
libhivex (but not libhivex-dev) needs to include the ABI number in the
package name. Please read libpkg-guide and its two bug reports:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
http://bugs.debian.org/libpkg-guide
You added several hardcoded library dependencies, please leave it to
the shlibs mechanism to resolve them at build time.
You Depend on Perl, I think you meant perl?
debian/changelog does not close an ITP bug, only a LaunchPad bug.
debian/copyright misses some information, some files are GPL not LGPL.
You might want to adopt DEP-5 for debian/copyright:
http://dep.debian.net/deps/dep5/
pod2html complaints:
/usr/bin/pod2html: sh/hivexsh.pod: unknown pod directive 'encoding' in
paragraph 1. ignoring.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lhivex(3) in paragraph 8.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lvirt-cat(1) in paragraph 8.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lguestfish(1) in
paragraph 8.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lhivex(3)/WRITING
TO HIVE FILES in paragraph 22.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lhivex(3) in paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lhivexget(1) in
paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lhivexml(1) in paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lvirt-win-reg(1)
in paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lguestfs(3) in paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lvirt-cat(1) in
paragraph 73.
/usr/bin/pod2html: sh/hivexsh.pod: cannot resolve Lvirt-edit(1) in
paragraph 73.
dpkg-shlibdeps complaint:
dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be
avoided if debian/hivex/usr/bin/hivexsh were not uselessly linked
against it (they use none of its symbols).
dpkg-gencontrol complaints:
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Enhances}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Provides}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Conflicts}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Pre-Depends}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Replaces}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Depends}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Recommends}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Suggests}
dpkg-gencontrol: warning: unused substitution variable ${cdbs:Breaks}
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unused substitution variable ${perl:Depends}
lintian complaints:
lintian --info --display-info --display-experimental --pedantic
--show-overrides --checksums --color auto
I: hivex source: duplicate-short-description libhivex libhivex-dev
hivex libhivex-perl libhivex-ocaml
O: hivex source: maintainer-not-full-name TJ
W: libhivex-dev: new-package-should-close-itp-bug
W: libhivex-dev: maintainer-not-full-name TJ
W: libhivex-dev: wrong-section-according-to-package-name libhivex-dev
= libdevel
W: libhivex: package-name-doesnt-match-sonames libhivex0
W: libhivex: new-package-should-close-itp-bug
W: libhivex: maintainer-not-full-name TJ
W: libhivex: non-dev-pkg-with-shlib-symlink usr/lib/libhivex.so.0.0.0
usr/lib/libhivex.so
I: libhivex: no-symbols-control-file usr/lib/libhivex.so.0.0.0
W: libhivex-ocaml: new-package-should-close-itp-bug
W: libhivex-ocaml: maintainer-not-full-name TJ
P: libhivex-ocaml: ocaml-dev-file-in-nondev-package 3 files in /usr/lib/ocaml
W: hivex: new-package-should-close-itp-bug
W: hivex: maintainer-not-full-name TJ
I: hivex: spelling-error-in-manpage
usr/share/man/man1/hivexregedit.1.gz reencode re-encode
I: hivex: spelling-error-in-manpage
usr/share/man/man1/hivexregedit.1.gz reencode re-encode
E: libhivex-perl: binary-or-shlib-defines-rpath
./usr/lib/perl/5.10.1/auto/Win/Hivex/Hivex.so
/tmp/buildd/hivex-1.2.1/perl/../lib/.libs
W: libhivex-perl: new-package-should-close-itp-bug
W: libhivex-perl: maintainer-not-full-name TJ
W: libhivex-perl: wrong-section-according-to-package-name libhivex-perl = perl
E: libhivex-perl: perl-module-in-core-directory usr/lib/perl/5.10.1/
: libhivex-perl: perl-module-in-core-directory usr/lib/perl/5.10.1/Win/
E: libhivex-perl: perl-module-in-core-directory usr/lib/perl/5.10.1/Win/Hivex.pm
E: libhivex-perl: perl-module-in-core-directory usr/lib/perl/5.10.1/Win/Hivex/
E:
Re: RFS: ruby-hdfeos5
Hi, Timeline: Thu, 1 Apr 2010 07:33:52 +0200: [Francesco P. Lovergine fran...@debian.org] wrote: On Fri, Mar 19, 2010 at 11:00:29AM +0900, Youhei SASAKI wrote: I am looking for a sponsor for my package ruby-hdfeos5. If none had already catched this request, I can do the sponsoring. Please, confirm. I'm so happy! :-) It would be greatly appreciated if you could help me to sponsor upload. Now, I upload ruby-hdfeos5 to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=ruby-hdfeos5 Kind Regeards, --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 1024/DSA: 8BF1 ABFE 00D2 526D 6822 2AC6 13E0 381D AEE9 95F4 -- 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/20100402.125426.1018102418641079621.uwab...@gfd-dennou.org
