RFS: iptotal (updated package) (2nd try)
Dear mentors, I am looking for a sponsor for the new version 0.3.3-12 of my package iptotal. It builds these binary packages: iptotal- monitor for IP traffic, not requiring SNMP The package appears to be lintian clean. The upload would fix these bugs: 572246 (grave), 574121 (important) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/iptotal - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/iptotal/iptotal_0.3.3-12.dsc I would be glad if someone reviewed/uploaded this package for me. Kind regards, Ignace Mouzannar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b10d7e9c1003290109o19d99f9boc899f57c42e86...@mail.gmail.com
Re: RFS: django-picklefield
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Issues with upstream code: - According to upstream README[2], the implementation is taken and adopted from [a snippet] by Taavi Taijala; this is apparently in contrast with the only copyright statement (in setup.py): Copyright (c) 2009 Shrubbery Software. Could you please clarify this with upstream? - According to docstrings the pickling protocol is specified explicitly (by default 2), which is not true (unless I'm blind). I've uploaded a new version of the package with fixed pickling protocol version handling and clarified copyright statements. All my patches were included in upstream. http://mentors.debian.net/debian/pool/main/d/django-picklefield/django-picklefield_0.1.3-1.dsc Could you take a look at it? Thank you, Michael [2] http://github.com/shrubberysoft/django-picklefield -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuwYoMACgkQeJ3z1zFMUGb7lACgkhwHZYZkF8LWX/7BR232fy+L ErIAn0Gr2R3+LS/gqV5iXrNu5mJSIaAT =am7O -END PGP SIGNATURE- -- 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/hopnq4$i9...@dough.gmane.org
Re: RFS: iptotal (updated package) (2nd try)
On Mon, Mar 29, 2010 at 10:09:28AM +0200, Ignace Mouzannar wrote: Dear mentors, I am looking for a sponsor for the new version 0.3.3-12 of my package iptotal. It builds these binary packages: iptotal- monitor for IP traffic, not requiring SNMP The package appears to be lintian clean. The upload would fix these bugs: 572246 (grave), 574121 (important) I'm not convinced your fix is the best way to go. Is iptotal unusable with apache2? I thought it would be better to support apache2 and perform better checks (however you do that) in post* for the web server reloads. Don't you think? Hauke signature.asc Description: Digital signature
Re: RFS: django-picklefield
* Michael Fladischer mich...@fladi.at, 2010-03-29, 10:19: Issues with upstream code: - According to upstream README[2], the implementation is taken and adopted from [a snippet] by Taavi Taijala; this is apparently in contrast with the only copyright statement (in setup.py): Copyright (c) 2009 Shrubbery Software. Could you please clarify this with upstream? - According to docstrings the pickling protocol is specified explicitly (by default 2), which is not true (unless I'm blind). I've uploaded a new version of the package with fixed pickling protocol version handling and clarified copyright statements. All my patches were included in upstream. http://mentors.debian.net/debian/pool/main/d/django-picklefield/django-picklefield_0.1.3-1.dsc I can't see how the copyright issue was resolved. We have Copyright (c) 2009-2010 Gintautas Miliauskas in setup.py, and Copyright (c) 2009, Shrubbery Software Copyright (c) 2009, Taavi Taijala Copyright (c) 2007, Oliver Beattie in debian/copyright... There are some stale files in debian/ that should be removed from the source package: debian/python-picklefield.* debian/python-module-stampdir debian/stamp-patched Tests should not be run if nocheck build option is enabled (see Debian Policy 4.9.1 and bug #568897). It would be nice if tests were run with all versions of Python your package supports. `pyversions -r` can give you such a list. You could try to generate upstream changelog from the README file. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFS: pulseaudio (updated package)
Il 28/03/2010 23:41, Michael Gilbert ha scritto: Those are just guidelines, right? Yes they are, the purpose of developers-reference is to provide an overview of the recommended procedures. Cheers, Giuseppe signature.asc Description: OpenPGP digital signature
Re: RFS: django-picklefield
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Wilk, 2010-03-29 14:12: I can't see how the copyright issue was resolved. We have Copyright (c) 2009-2010 Gintautas Miliauskas in setup.py, and Copyright (c) 2009, Shrubbery Software Copyright (c) 2009, Taavi Taijala Copyright (c) 2007, Oliver Beattie in debian/copyright... I'll make sure that upstream sorts this out. Gintautas Miliauskas is (or at least was) in fact the person behind Shrubbery Software. There are some stale files in debian/ that should be removed from the source package: debian/python-picklefield.* debian/python-module-stampdir debian/stamp-patched Should I remove them through dh_auto_clean? Tests should not be run if nocheck build option is enabled (see Debian Policy 4.9.1 and bug #568897). Fixed this. It would be nice if tests were run with all versions of Python your package supports. `pyversions -r` can give you such a list. How do I make sure that all supported versions do get installed as Build-Deps because currently only python2.5 gets pulled in during 'pdebuild'? You could try to generate upstream changelog from the README file. I'm not that much of an awk/sed wizard to do that. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuwqTQACgkQeJ3z1zFMUGYmwACggwgzQrA6VdsMjlEpZdRlEctW 9MkAn37oxx7ZftRB8ii1SW6Kv+leuOnX =UAzP -END PGP SIGNATURE- -- 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/hoq9fq$ho...@dough.gmane.org
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 10:11:09AM -0300, Tatiana Al-Chueyr wrote: Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? I had a (quick) look at Thiagos packaging[2] and while the package builds somehow there are several lintian warnings. If you try lintian -i *.dsc *.deb you get explanations and several of these are relatively easy to fix. An absolute no go is the missing copyright information which definitely needs fixing. Please try to work down the list of lintian problems and feel free to ask for any help if something remains unclear. BTW, it might make sense to join a packaging team on alioth (python-modules-team ??) and use their SVN for the packaging stuff. This enables potential helpers for packaging to commit changes easily. Hope this helps for the moment Andreas. [1] http://lists.debian.org/debian-mentors/2010/03/msg00324.html [2] http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc -- http://fam-tille.de -- 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/20100329134010.ga2...@an3as.eu
Re: RFS: django-picklefield
* Michael Fladischer mich...@fladi.at, 2010-03-29, 15:20:
There are some stale files in debian/ that should be removed from the
source package:
debian/python-picklefield.*
debian/python-module-stampdir
debian/stamp-patched
Should I remove them through dh_auto_clean?
No, they look like artifacts after cdbs-dh switch and binary package
rename. Remove them once and they should go away forever.
It would be nice if tests were run with all versions of Python your
package supports. `pyversions -r` can give you such a list.
How do I make sure that all supported versions do get installed as
Build-Deps because currently only python2.5 gets pulled in during
'pdebuild'?
Build-depend on python-all (= 2.5).
You could try to generate upstream changelog from the README file.
I'm not that much of an awk/sed wizard to do that.
Something line this should work:
sed -n -e '/^Changes in version/,$ { /^---/q; p }' README
(Don't forget to replace $ with $$ if you use this snippet in Makefile.)
--
Jakub Wilk
signature.asc
Description: Digital signature
Re: RFS: iptotal (updated package) (2nd try)
Hello Hauke, On Mon, Mar 29, 2010 at 10:55, Jan Hauke Rahm j...@debian.org wrote: On Mon, Mar 29, 2010 at 10:09:28AM +0200, Ignace Mouzannar wrote: Dear mentors, I am looking for a sponsor for the new version 0.3.3-12 of my package iptotal. It builds these binary packages: iptotal - monitor for IP traffic, not requiring SNMP The package appears to be lintian clean. The upload would fix these bugs: 572246 (grave), 574121 (important) I'm not convinced your fix is the best way to go. Is iptotal unusable with apache2? I thought it would be better to support apache2 and perform better checks (however you do that) in post* for the web server reloads. Don't you think? As iptotal should work with other web-servers supporting CGI, I chose to remove the automatic linking and reloading of apache's configuration. I find it cleaner to start the iptotal daemon, and let the user enable the cgi samples that are shipped within the package, and reload his webserver. What do you think about that? Kind regards, Ignace M -- 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/b10d7e9c1003290919n51ac267cr9802f894a8c92...@mail.gmail.com
Re: RFS: iptotal (updated package) (2nd try)
Hi Ignace, On Mon, Mar 29, 2010 at 06:19:23PM +0200, Ignace Mouzannar wrote: On Mon, Mar 29, 2010 at 10:55, Jan Hauke Rahm j...@debian.org wrote: I'm not convinced your fix is the best way to go. Is iptotal unusable with apache2? I thought it would be better to support apache2 and perform better checks (however you do that) in post* for the web server reloads. Don't you think? As iptotal should work with other web-servers supporting CGI, I chose to remove the automatic linking and reloading of apache's configuration. I find it cleaner to start the iptotal daemon, and let the user enable the cgi samples that are shipped within the package, and reload his webserver. What do you think about that? On a second look at the package I found that this is probably the best aproach, yes. I would suggest mentioning such in a README.Debian file where you could also write about the files being moved around in postinst. But that's your call. As a user I would probably be confused if files moved from /var/www to /usr/lib to /var/lib. :) Also, I just saw postrm is empty basically. Please remove it. Hauke PS: No need to CC me, btw :) signature.asc Description: Digital signature
Upstream name change
Hi mentors, I maintain dajaxice package, but the upstream author has changed the name to django-dajaxice. What is the best option? Maintain the actual source name in package? or change it to django-dajaxice? If I should change de source name, Could somebody explain what is the procedure? Thanks in advance! -- 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/6fc1ef361003290939l219f60d2m45d4a33ec0556...@mail.gmail.com
Re: RFS: iptotal (updated package) (2nd try)
A quick hint below. As I have not got the complete picture, do bare with me if I misunderstood the remark. måndag den 29 mars 2010 klockan 18:42 skrev Jan Hauke Rahm detta: Hi Ignace, On Mon, Mar 29, 2010 at 06:19:23PM +0200, Ignace Mouzannar wrote: On Mon, Mar 29, 2010 at 10:55, Jan Hauke Rahm j...@debian.org wrote: reloads. Don't you think? As iptotal should work with other web-servers supporting CGI, I chose his webserver. What do you think about that? postinst. But that's your call. As a user I would probably be confused if files moved from /var/www to /usr/lib to /var/lib. :) Any non-webserver package installing files into /var/www would violate LHS policy. Right? I did repare a handful such violations this past winter. 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/20100329171836.ga29...@mea.homelinux.org
Re: RFS: iptotal (updated package) (2nd try)
On Mon, Mar 29, 2010 at 07:18:36PM +0200, Mats Erik Andersson wrote: A quick hint below. As I have not got the complete picture, do bare with me if I misunderstood the remark. måndag den 29 mars 2010 klockan 18:42 skrev Jan Hauke Rahm detta: Hi Ignace, On Mon, Mar 29, 2010 at 06:19:23PM +0200, Ignace Mouzannar wrote: On Mon, Mar 29, 2010 at 10:55, Jan Hauke Rahm j...@debian.org wrote: reloads. Don't you think? As iptotal should work with other web-servers supporting CGI, I chose his webserver. What do you think about that? postinst. But that's your call. As a user I would probably be confused if files moved from /var/www to /usr/lib to /var/lib. :) Any non-webserver package installing files into /var/www would violate LHS policy. Right? I did repare a handful such violations this past winter. *Any* package installing files into /var/www violates FHS/policy as that's the web root for the system admin, not the maintainer. Thus the changes in the package here and the moving around of old files in postinst. Hauke signature.asc Description: Digital signature
RFS: php-log (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.12.0-1 of my package php-log. It builds these binary packages: php-log- log module for PEAR The package appears to be lintian clean. The upload would fix these bugs: 572265 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-log - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-log/php-log_1.12.0-1.dsc I would be glad if someone uploaded this package for me. -- Guillaume Delacour signature.asc Description: OpenPGP digital signature
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: On Mon, Mar 29, 2010 at 10:11:09AM -0300, Tatiana Al-Chueyr wrote: Until now, we haven't had advances on SIGAR packaging [1]. How should we proceed? I had a (quick) look at Thiagos packaging[2] and while the package builds somehow there are several lintian warnings. If you try lintian -i *.dsc *.deb you get explanations and several of these are relatively easy to fix. An absolute no go is the missing copyright information which definitely needs fixing. Please try to work down the list of lintian problems and feel free to ask for any help if something remains unclear. BTW, it might make sense to join a packaging team on alioth (python-modules-team ??) and use their SVN for the packaging stuff. This enables potential helpers for packaging to commit changes easily. Hope this helps for the moment Andreas. [1] http://lists.debian.org/debian-mentors/2010/03/msg00324.html [2] http://dl.dropbox.com/u/817671/packages/sigar_1.7.0%7Esvn5287-1.dsc -- http://fam-tille.de Thanks Andreas, I fixed some of lintian problems. One of the problems that remains is: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) Thanks!
Re: Status of SIGAR (Was: InVesalius packaging)
Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.dewrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- 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/20100329192755.ga22...@meiner
RFS: gdisk (updated package, new upstream release)
Dear mentors, I am looking for a sponsor for the new version 0.6.6-1 of my package gdisk. This package is a new upstream release and fix debian/watch file. It builds these binary packages: gdisk - GPT fdisk text-mode partitioning tool The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gdisk - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gdisk/gdisk_0.6.6-1.dsc I would be glad if someone uploaded this package for me. -- Guillaume Delacour signature.asc Description: OpenPGP digital signature
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 4:27 PM, Michael Hanke michael.ha...@gmail.comwrote: Hey, On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: On Mon, Mar 29, 2010 at 10:40 AM, Andreas Tille andr...@fam-tille.de wrote: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I wasn't following this effort before -- forgive me if that had been talked about before. Looks like the Python-bindings (and others too) should go into separate binary packages and be handled by proper tools. pysupport should take care of all Python-related issue (including the one above). Is there any reason for this verbose rules file. Both debhelper7 and cdbs should help a lot with the common cases of packaging (like this one) and also provide convenient helpers for python packages. I might be able to help with the general and python-related aspects of this packaging, but wanted to ask first if there is need to stay close to the current state? Right now the packaging looks quite raw -- lots of unused/unedited files. The rules file only seems to build the python-bindings and none of the rest -- including the main library -- is that intended? Given these facts the binary package should be named 'python-sigar'. Is there a repository for this packaging somewhere? You chose to take an SVN snapshot (upstream also offers the code in git). Did you just download that snapshot or have the code in a repository together with the packaging? Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- 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/20100329192755.ga22...@meiner Hi Michael, No, it's not needed to stay close to the current state. I only packaged the python-bindings because the project I work [1] needs only the python-bindings. The last stable version from sigar doesn't compile, then it was necessary to compile the trunk version (svn or git). The package is in our Download page [2] (Ubuntu and Fedora). Thanks for help! [1] - http://svn.softwarepublico.gov.br/trac/invesalius/ [2] - http://svn.softwarepublico.gov.br/trac/invesalius/wiki/downloads/3.0-beta-2#GNULinuxInstaller
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 4:36 PM, Andreas Tille andr...@fam-tille.de wrote: On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: I fixed some of lintian problems. One of the problems that remains is: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I have limited experience with python packages but the principle is that the *.pyc files will be created at package install time in the postinst script. This is done by python-support and is described in the Debian Python Policy[1]. Perhaps you might have a look into this document and if something remains unclear, it is a good idea to ask on debian-mentors. Kind regards Andreas. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ -- http://fam-tille.de Ok, Andreas, I'm reading that.
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 03:46:20PM -0300, Thiago Franco Moraes wrote: I fixed some of lintian problems. One of the problems that remains is: W: libsigar: package-installs-python-pyc usr/lib/python2.6/dist-packages/sigar.pyc N: N:Compiled python source files should not be included in the package. N:These files should be removed from the package and created at package N:installation time in the postinst. N: N:Severity: normal, Certainty: certain How can I only compile in installation time? I'm using this command in rule file to install the files: cd $(CURDIR)/bindings/python python setup.py install --install-layout=deb --root=$(CURDIR)/debian/$(PACKAGE) I have limited experience with python packages but the principle is that the *.pyc files will be created at package install time in the postinst script. This is done by python-support and is described in the Debian Python Policy[1]. Perhaps you might have a look into this document and if something remains unclear, it is a good idea to ask on debian-mentors. Kind regards Andreas. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ -- http://fam-tille.de -- 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/20100329193611.gb16...@an3as.eu
Re: RFS: pulseaudio (updated package)
Michael Gilbert scrisse: +nmuX should be used only for native packages, please refer to d-reference 5.11.2[1] Those are just guidelines, right? As long as the new version is viewed as incremental compared to the last one, it should be ok I think. See same section (5.11.2) for suggested naming for uploads to stable, which is not followed at since codenames are a lot cleaner. Both of you may be interested in §5.11.1.1 of DEP1: http://dep.debian.net/deps/dep1.html Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpP3psvFHTPz.pgp Description: PGP signature
Re: Upstream name change
Angel Abad angela...@gmail.com wrote: Hi mentors, I maintain dajaxice package, but the upstream author has changed the name to django-dajaxice. What is the best option? Maintain the actual source name in package? or change it to django-dajaxice? If I should change de source name, Could somebody explain what is the procedure? This theme was discussed some weeks before. There was said the main problem is, if you change the source name you begin with a new package. All infos about the (old) package stay inside debian until this package will be deleted. With the beginning of the (new) package it has to start in the NEW queue and then it is a new package without any history. Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: RFS: iptotal (updated package) (2nd try)
Hello Hauke, On Mon, Mar 29, 2010 at 18:42, Jan Hauke Rahm j...@debian.org wrote: Hi Ignace, On Mon, Mar 29, 2010 at 06:19:23PM +0200, Ignace Mouzannar wrote: On Mon, Mar 29, 2010 at 10:55, Jan Hauke Rahm j...@debian.org wrote: I'm not convinced your fix is the best way to go. Is iptotal unusable with apache2? I thought it would be better to support apache2 and perform better checks (however you do that) in post* for the web server reloads. Don't you think? As iptotal should work with other web-servers supporting CGI, I chose to remove the automatic linking and reloading of apache's configuration. I find it cleaner to start the iptotal daemon, and let the user enable the cgi samples that are shipped within the package, and reload his webserver. What do you think about that? On a second look at the package I found that this is probably the best aproach, yes. I would suggest mentioning such in a README.Debian file where you could also write about the files being moved around in postinst. But that's your call. As a user I would probably be confused if files moved from /var/www to /usr/lib to /var/lib. :) I have added a README.debian explaining the directory changes, and the way to configure iptotal with apache2. (I also modified the README.source file to state quilt instead of dpatch.) Also, I just saw postrm is empty basically. Please remove it. Thank you for noticing that. The file has been removed. PS: No need to CC me, btw :) Done ;) I have uploaded a new version of the package on m.d.n [1]. Thank you for your time and consideration. Cheers, Ignace M [1] The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/iptotal - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/iptotal/iptotal_0.3.3-12.dsc -- 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/b10d7e9c1003291737p309e3133pdfcf116e20788...@mail.gmail.com
Re: RFS: iptotal (updated package) (2nd try)
On Tue, Mar 30, 2010 at 2:01 AM, Jan Hauke Rahm j...@debian.org wrote: *Any* package installing files into /var/www violates FHS/policy as that's the web root for the system admin, not the maintainer. Thus the changes in the package here and the moving around of old files in postinst. Somewhere under /srv is a better location for the web root(s) and data managed by the sysadmin. -- 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/e13a36b31003291742o2cfb57afh9d95e388e0897...@mail.gmail.com
RFS: libspring-webflow-2.0-java
Hi mentors, I am looking for a sponsor for my package libspring-webflow-2.0-java. * Package name: libspring-webflow-2.0-java Version : 2.0.8.RELEASE-1 Upstream Author : SpringSource Inc. * URL : http://www.springsource.com/webflow * License : Apache-2.0, BSD and others Section : java It builds these binary packages: libspring-js-2.0-java - JavaScript abstraction framework libspring-webflow-2.0-java - Java MVC framework focused in View and Controller layers libspring-webflow-2.0-java-doc - documentation for libspring-webflow-2.0-java The package is lintian clean. The upload would fix these bugs: 575850. My motivation for maintaining this package is: I develop software using this library. Also it is needed on the server-side. Additionally, this software is needed by other software that I'm packaging. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libspring-webflow-2.0-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libspring-webflow-2.0-java/libspring-webflow-2.0-java_2.0.8.RELEASE-1.dsc - Vcs-Git: git://git.debian.org/pkg-java/libspring-webflow-2.0-java.git I would be glad if someone uploaded this package for me. Regards, -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ Faith means not wanting to know what is true. -- Nietzsche -- 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/86aeadee1003291811m134d3708i594fa1f00573b...@mail.gmail.com
RFS: sciteproj (updated package)
Dear mentors, I am looking for a sponsor for my SciteProj package: Sciteproj is a project manager, giving the possibility to arrange files in a project, for easy access in the SciTE editor. The project is saved to disk in XML format. It uses CMake as build system and its only requirement is GTK and SciTE. SciteProj is released under the GPL version 3. It is availible on Mentors: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=sciteproj The dsc, diff.gz and tar.gz is availible here: http://mentors.debian.net/debian/pool/main/s/sciteproj/ Direct link to dsc: http://mentors.debian.net/debian/pool/main/s/sciteproj/sciteproj_0.3.6-1.dsc Upstream (I am the upstream) homepage is located at http://sciteproj.sourceforge.net The upload would fix these bugs: 513231. Best regards -- Andreas Rönnquist gus...@gusnan.se -- 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/20100330060010.b242025c.gus...@gusnan.se
