Re: RFS: wmanager - updated package
On Thu, Jul 03, 2008 at 01:43:00AM +0300, Peter Pentchev wrote: > Hi, > > I am looking for a sponsor for the new version 0.2.1-4 of my package > "wmanager". The last-time sponsor is currently busy, so I hope I could > find somebody interested here :) I'm happy to have uploaded this one. Its a useful package for me. thanks, stew signature.asc Description: Digital signature
Re: RFS: freemat
Bernhard R. Link ha scritto: > * Giuseppe Iuculano <[EMAIL PROTECTED]> [070912 12:14]: >> Done, and re-uploaded. > > Some more issues: > > * you build-depend on autotools-dev and delete those file unconditionally, > so there is no need to only copy config.guess and config.sub in if they > are there. (i.e: remove the ifneq and endif around the copies) > (Mostly a cosmetic issue) > Acutally, as you tell autoreconf an -f -i, it might even copy them there > a second time. (-f also modifies INSTALL, so perhaps without -f is better) > > * You miss a build-dependency on pkg-config. (And upstream's configure > or something included by this needs better error reporting, most likely > the m4 files from pkg-config). Fixed. I removed also autoreconf, Makefile calls aclocal,automake,autoconf > > * After this unpatch no longer works. I think this is because you patch > Makfile.in files. As you call autoreconf, this can only be harmfull. > > * running autoreconf changes many files, many are not reverted by your > clean. I don't know how fix this, I need patching Makefile.in to fix UMFPACK search and so I need to call aclocal/automake/autoconf... How can I fix this? > (and no not forget to make the config.status rule then depend > configure.in instead of configure) Fixed > > * you might want to tell upstream to tell whoever is responsible for > AC_LIB_FREEMAT_CHECK in acinclude.m4, that neighter CFLAGS nor CXXFLAGS > are suiteable places to put -I in (-I and -D belong only in CPPFLAGS, > never ever into CFLAGS or CXXFLAGS). > (heck, configure even print warnings about not finding umfpack.h in the >preprocessor because of this). Ok, I'm going to open a bug in freemat sourceforge bug tracker. > > There might still be other issues, I did not yet give it a thourough look. > (took me some time to figure out it was pkg-config missing and c++ is > really slow, did not yet even do a full compile yet...) Thanks, reuploaded on mentors. Giuseppe Iuculano. signature.asc Description: OpenPGP digital signature
Re: RFS: P4A - PHP For Applications
Andrea Giardina wrote: > Hello to everybody, > I'm searching a sponsor to upload p4a dep package on Debian. > ... Could you please provide more information? and not just marketing-like information please. > > You can find the debian package and changes here: > http://p4a.crealabsfoundation.org/deb/ Next time please provide the uri of the .dsc and _sign_ your package. debian/copyright: > This program is free software: you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation, either version 2.1 of the License. looks like some part of it is missing debian/control: Like above, please improve the description debian/changelog: What about telling _what_ changes you made, instead of just telling 'fix on file foo'? Otherwise the changelog is not very useful. debian/debhelper.log: Should not be there debian/Makefile: debian/postinst: WEBSERVERS="apache apache-ssl apache2" the first two no longer exist. why don't you just ship the file directly into apache2's config dir? debian/postrm: > purge|remove) config files must not be removed on 'remove', only on purge. p4a/libraries/Zend/: please don't do that, package the zend framework separately so other packages and projects can use it, and then make the necessary changes in your application to use the shared version. ... same as for fckeditor, jquery, and all the other stuff that isn't from p4a. There are some other issues but the above mentioned should be addressed first. > > Thanks for the help > Andrea Giardina Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
On Wed, 2008-07-02 at 12:22 -0500, William Vera wrote: > In fact it's de only place where you set de epoch, (please correct me > if I'm wrong) > Then before must be ok. It's exactly as it should be, just me being blind; didn't see the last version being 1.32 . > > > > You should add a debian/watch file > > Added The watch-file doesn't seem to work correctly. Consider changing the content to something like: version=3 opts="uversionmangle=s/(alpha|beta|rc)/~$1/" \ http://sf.net/nemesis/nemesis-(.*)\.tar\.gz The rest of the changes looks good. Also remember to delete the aclocal.m4, config.h.in and configure files before making the diff.gz to get rid of the "patch-system-but-direct-changes-in-diff" lintian warnings. Cheers, Andreas -- Andreas Wenning <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: wmanager - updated package
Hi, I am looking for a sponsor for the new version 0.2.1-4 of my package "wmanager". The last-time sponsor is currently busy, so I hope I could find somebody interested here :) It builds these binary packages: wmanager - Select a window manager at X startup The highlights of this update are: * Convert the package build to debhelper, minimizing the rules file. * Convert the copyright file to the new format. * The wmanager home site has risen from the dead, so add a watchfile. * Convert the manual pages to mdoc format. * Make the support scripts a bit more portable. The changelog entry has more detailed information. The package has been tested with lintian on the testing and unstable distributions. The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-4.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpqPG0b3wICe.pgp Description: PGP signature
Re: debconf database and config files
Christoph Biedl wrote: > The given "config" file sources $CONFIGFILE if present but asserts > FOO and BAR are defined there. Is this safe? I'd rather wipe out any > pre-existing values: > > # Load config file, if it exists. > if [ -e $CONFIGFILE ]; then > + FOO= > + BAR= > . $CONFIGFILE || true I belive this is good practice to do. (In init scripts too.) > * "postinst" sample > > If I understand correctly, all the logic shown applies only for the > "configure" invocation. Or did I miss something? Therefore the > sample should be embedded in a switch like If you look in HACKS, it describes why sourcing the confmodule needs to be before nearly anything else in your script. So I prefer to keep it very close to the top in my examples. > * config file default values > > It is quite common to ship a /etc/default/daemon in the package. > However, this leads to the situation that default values are stored in > three different locations: > * debian/default as set up by the maintainer > * debian/template for debconf > * debian/postinst where the file is created if missing > > I doubt this is the best solution. If you're managing the file with debconf, then it should not be a conffile, so should not be included in the package. I don't see any need to hardcode the default value in the postinst. -- see shy jo signature.asc Description: Digital signature
debconf database and config files
Hello, Perhaps I'm just too timid for a bug report against debconf-doc but at the moment there are too many things I haven't fully understood yet. Basic problem: A daemon, started as usual via /etc/init.d/daemon, and it gets additional parameters via a config file /etc/default/daemon. The system administrator should be able to configure that information during installation, i.e. debconf. After reading debconf-devel(7) several questions remained. * "config" sample The given "config" file sources $CONFIGFILE if present but asserts FOO and BAR are defined there. Is this safe? I'd rather wipe out any pre-existing values: # Load config file, if it exists. if [ -e $CONFIGFILE ]; then + FOO= + BAR= . $CONFIGFILE || true # Store values from config file into # debconf db. db_set mypackage/foo "$FOO" db_set mypackage/bar "$BAR" fi On a side note, the same holds for virtually every init script that sources a config file. * "postinst" sample If I understand correctly, all the logic shown applies only for the "configure" invocation. Or did I miss something? Therefore the sample should be embedded in a switch like #!/bin/sh case "$1" in configure) # code as in debconf-devel(7) here CONFIGFILE=/etc/foo.conf set -e . /usr/share/debconf/confmodule (...) mv -f $CONFIGFILE.tmp $CONFIGFILE # end of code as in debconf-devel(7) ;; abort-upgrade|abort-remove|abort-deconfigure) # other cases here ;; (...) esac This would have helped my understanding a lot. * config file default values It is quite common to ship a /etc/default/daemon in the package. However, this leads to the situation that default values are stored in three different locations: * debian/default as set up by the maintainer * debian/template for debconf * debian/postinst where the file is created if missing I doubt this is the best solution. * Which "config" script is the good one? debconf-devel(7) presents two "config" scripts. The first in "Config file handling" with, as the name says, proper handling of a config file. The second, way better in its capabilities, in "Letting the user back up" but without config file handling. This leaves me in the unhappy situation a really useful example is still missing. Of course I can merge both but leaving this task to the developer is not a good solution. * Putting everything together I feel the whole process isn't as comfortable as it could be. The "config" part always will always remain handwork since only the maintainer knows about the interdependencies of the variables and where and how to back up. But the "postinst" part looks like it could be automated entirely. All information such a program needs is the name of the config file and a mapping between the debconf and the shell variables. Such a program could also add missing variables in a more sophisticated way that sed does, i.e. detect a setting commented out and place the definition there. And it would create a new config file only if required. Comments? Corrections? Christoph signature.asc Description: Digital signature
Re: RFS: giver
Hello! I've had a quick look at your package, and even though I'm no expert on c# I think it could use some additional work to reach perfection. Please see the Debian CLI Policy http://pkg-mono.alioth.debian.org/cli-policy/ There are some stuff like using dh_clideps which is an absolute minimum for a C# package as far as I know. You should be able to find alot of other useful hints in there as well to improve your package. You'll find experts on this topic in #debian-mono on irc.OFTC.net (aka. irc.debian.org). You should probably ask them for review of your package as well! You should also try running lintian against your packages .changes file after building it. You'll get some warnings and with the -i switch you'll get some hints on fixes. Last but not least I'd like to question your choice of using GPL licensing for the package of a program licensed under MIT. This might cause trouble when sending things upstream (atleast if you get contributions which you are not the copyright holder of yourself and need to ask for permission to relicense). I recommend every maintainer do this regularly with as much as possible to keep the differences as small. (You could start with your manual page for example.) HTH, HAND. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
Hello Andreas 2008/7/2 Andreas Wenning <[EMAIL PROTECTED]>: > Hi William > > Not a DD, but has a few points you should consider looking into: > > You did an epoch of the package calling it 1:1.4-1; any special reason > for that, if not you should change the version in debian/changelog > to 1.4-1. In fact it's de only place where you set de epoch, (please correct me if I'm wrong) Then before must be ok. > > The debian/copyright looks out-dated; you should look at changing the > license/copyright part of the file, and supply the new URL to the > upstream site. Updated > > You should add a debian/watch file Added . > > Running "lintian -I" against the generated .deb gives a lot of "I: > nemesis: hyphen-used-as-minus-sign". There was a discussion on this list > about how to change this within the last few weeks, but can't seem to > find the message just now. Fixed > > That was all I could find just now. > > Cheers, > Andreas Thanks for you review, the package is in the same location: http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-1.dsc Regards > -- > Andreas Wenning <[EMAIL PROTECTED]> > > On Wed, 2008-07-02 at 03:37 -0500, William Vera wrote: >> Dear mentors, >> >> I am looking for a sponsor for the new version 1:1.4-1 >> of my package "nemesis". >> >> It builds these binary packages: >> nemesis- TCP/IP Packet Injection Suite >> >> The upload would fix these bugs: 405459, 483700 >> >> The package can be found on mentors.debian.net: >> - URL: http://mentors.debian.net/debian/pool/main/n/nemesis >> - Source repository: deb-src http://mentors.debian.net/debian unstable >> main contrib non-free >> - dget http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-1.dsc >> >> I would be glad if someone uploaded this package for me. >> >> Kind regards >> William Vera >> >> >> -- >> William Vera <[EMAIL PROTECTED]> >> PGP Key: 1024D/F5CC22A4 >> Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 >> >> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- William Vera <[EMAIL PROTECTED]> PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4
RFS: P4A - PHP For Applications
Hello to everybody, I'm searching a sponsor to upload p4a dep package on Debian. P4A is a PHP5 RAD and object oriented framework for building event-driven stateful web applications. It's a project born in 2003 and published under the Affero GPL v3. You can find major information about it here: http://sourceforge.net/projects/p4a http://p4a.crealabsfoundation.org http://freshmeat.net/projects/p4a You can find the debian package and changes here: http://p4a.crealabsfoundation.org/deb/ Thanks for the help Andrea Giardina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: moc (updated package)
Hi Elimar, * Elimar Riesebieter <[EMAIL PROTECTED]> [2008-07-01 23:55]: > On Tue, 01 Jul 2008 the mental interface of > Nico Golde told: > > Hi Elimar, > > * Elimar Riesebieter <[EMAIL PROTECTED]> [2008-07-01 21:56]: > > > I am looking for a sponsor for the new version > > > 1:2.5.0~alpha3+svn20080629-1 of > > > my package "moc". > > > > I'll happily sponsor this great player if you fix the > > copyright years in debian/copyright :) > > Done ;) > > Thanks for upload that incedible peace of software ;) Uploaded. Cheers Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp5jhtEyNVZQ.pgp Description: PGP signature
Re: RFS: freemat
* Giuseppe Iuculano <[EMAIL PROTECTED]> [070912 12:14]: > Done, and re-uploaded. Some more issues: * you build-depend on autotools-dev and delete those file unconditionally, so there is no need to only copy config.guess and config.sub in if they are there. (i.e: remove the ifneq and endif around the copies) (Mostly a cosmetic issue) Acutally, as you tell autoreconf an -f -i, it might even copy them there a second time. (-f also modifies INSTALL, so perhaps without -f is better) * You miss a build-dependency on pkg-config. (And upstream's configure or something included by this needs better error reporting, most likely the m4 files from pkg-config). * After this unpatch no longer works. I think this is because you patch Makfile.in files. As you call autoreconf, this can only be harmfull. * running autoreconf changes many files, many are not reverted by your clean. (and no not forget to make the config.status rule then depend configure.in instead of configure) * you might want to tell upstream to tell whoever is responsible for AC_LIB_FREEMAT_CHECK in acinclude.m4, that neighter CFLAGS nor CXXFLAGS are suiteable places to put -I in (-I and -D belong only in CPPFLAGS, never ever into CFLAGS or CXXFLAGS). (heck, configure even print warnings about not finding umfpack.h in the preprocessor because of this). There might still be other issues, I did not yet give it a thourough look. (took me some time to figure out it was pkg-config missing and c++ is really slow, did not yet even do a full compile yet...) Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
On Wed, 2008-07-02 at 16:38 +0200, Cyril Brulebois wrote: > Andreas Wenning <[EMAIL PROTECTED]> (02/07/2008): > > Running "lintian -I" against the generated .deb gives a lot of "I: > > nemesis: hyphen-used-as-minus-sign". There was a discussion on this list > > about how to change this within the last few weeks, but can't seem to > > find the message just now. > > The complete lintian message (“long description”) should help you find > references, and learn how to fix this. > It explains what the problem exactly is; but when the man-pages are supplied by upstream patching all of them might not be the best solution. I remember a message containing a sed command that might be helpful, and managed to find it now: http://lists.debian.org/debian-mentors/2008/06/msg00416.html Cheers, Andreas -- Andreas Wenning <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
Andreas Wenning <[EMAIL PROTECTED]> (02/07/2008): > Running "lintian -I" against the generated .deb gives a lot of "I: > nemesis: hyphen-used-as-minus-sign". There was a discussion on this list > about how to change this within the last few weeks, but can't seem to > find the message just now. The complete lintian message (“long description”) should help you find references, and learn how to fix this. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: php-clamavlib
Hello, On Wed, Jul 2, 2008 at 2:16 AM, Ben Finney < [EMAIL PROTECTED] <[EMAIL PROTECTED]>> wrote: > "Sandro Tosi" <[EMAIL PROTECTED]> writes: > > > On Wed, Jul 2, 2008 at 06:34, Ben Finney > > <[EMAIL PROTECTED]<[EMAIL PROTECTED]>> > wrote: > > > "Adam Sommer" <[EMAIL PROTECTED]> writes: > > > > > >> I am looking for a sponsor for the new version 0.13-1.2 of my > > >> package "php-clamavlib". > > > > > > Are you actually the maintainer? The current package version > > > (0.13-1.1) lists Jonas Gennart <[EMAIL PROTECTED]> as the > > > package maintainer. > > > > it's a NMU (*Non* Maintainer Upload), as the version clearly states. > > This is at odds with Adam referring to "my package". Hence my > question. > > If this was merely the result of not checking the text of a RFS > template to see if it makes sense, all the more reason to do that in > future. > > Apologies, when I first read that I assumed "my" was referring to the uploaded version of the package. I totally didn't intend to imply that I was the maintainer of the package. I will definitely read the templates more carefully in the future. Thank you Ben, Sandro, and Scott for reviewing my packaging attempt. -- Party On, Adam
Re: RFS: nemesis (updated package)
Hi William Not a DD, but has a few points you should consider looking into: You did an epoch of the package calling it 1:1.4-1; any special reason for that, if not you should change the version in debian/changelog to 1.4-1. The debian/copyright looks out-dated; you should look at changing the license/copyright part of the file, and supply the new URL to the upstream site. You should add a debian/watch file. Running "lintian -I" against the generated .deb gives a lot of "I: nemesis: hyphen-used-as-minus-sign". There was a discussion on this list about how to change this within the last few weeks, but can't seem to find the message just now. That was all I could find just now. Cheers, Andreas -- Andreas Wenning <[EMAIL PROTECTED]> On Wed, 2008-07-02 at 03:37 -0500, William Vera wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1:1.4-1 > of my package "nemesis". > > It builds these binary packages: > nemesis- TCP/IP Packet Injection Suite > > The upload would fix these bugs: 405459, 483700 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/n/nemesis > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-1.dsc > > I would be glad if someone uploaded this package for me. > > Kind regards > William Vera > > > -- > William Vera <[EMAIL PROTECTED]> > PGP Key: 1024D/F5CC22A4 > Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: lynis (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.7-1 of my package "lynis". It builds these binary packages: lynis - security auditing tool for Unix based systems Description: security auditing tool for Unix based systems Lynis is an auditing tool for Unix. It scans the system configuration and creates an overview of system information and security issues usable by professional auditors. It can assist in automated audits. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/lynis - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/lynis/lynis_1.1.7-1.dsc I would be glad if someone uploaded this package for me. Kind regards Francisco Manuel Garcia Claramonte -- Francisco M. García Claramonte <[EMAIL PROTECTED]> GPG: public key ID 556ABA51 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Re: RFS: bluemindo
Hi, sorry for my late reply. Has been a bit busy these days. On Sat, Jun 28, 2008 at 02:13:17PM +0200, Thibaut GIRKA wrote: > > - Important: You install an extra-license file which causes a lintian > > warning. Refer to Policy Manual, section 12.5 for details. Please > > always check your package against a recent lintian from unstable. > > Hm. The fact is that bluemindo reads the file itself. Due to the fact that its a GPL license you have the possibility to create a symlink to the file in /u/s/common-licenes. Or patch bluemindo. First choice probably preferrable. > > - debian/rules: > > Hm. You use CDBS, but you don't use python-distutils. You may want to > > change that. Otherwise you need to handle some things yourself. See > > [5] for some informations. > > Hm... Done (I think). Hm. Why don't you use the way thats written down in the CDBS docs [1]? Is there a special reason for your manual calling of dh_pysupport? I also don't think that this is enough. > > - debian/copyright: > > - Please don't throw copyright and license informations together. If > > you have parts in the source tarball that are not licensed the > > same way as the main program itself, then I recommend you to open > > another License block with an additional "(for ...)" that states > > which file is meant. BTW. what do you think about this [1] format? > > - (C) has no legal meaning. You have to replace it with ©. > > I changed it. I it better now? I see that you adopted the machine-parseable copyright format. So do you like it? However it seems still a bit bogus to me: Most files use the GPL-3 as license so citing parts of the license explicit is not needed and imho makes no sense, too. Additional you have a "License.." block at the end of the file, which is possibly un-needed (because the machine-parseable part replaces it) but in my opinion a good approach, because I really prefer to still have a human-readable part as long as there is no parser that makes the file more human-readable by people who are not so technical experienced. So to make your copyright perfect: - Remove license excerpts for well known licenses - Include complete license information for the PSF, because it is not in /u/s/common-licenses - Make the human readable part complete (e.g. re-add a Copyright part). > As the package provides a png file in the good place, can I use it? or > do I have to make a xmp file? Well, the most window managers probably don't understand the PNG format, so yes this is required. However you can do this automatically by converting the file with convert and build-depending on imagemagick. > > > - debian/README.source: > > You should rename it to .source instead of .Source because thats its > > filename according to policy. Otherwise its incomplete. It needs to > > document at a bare minimum: 1) Creating a fully-patched source, 2) > > Modifying the source and save those modifications to let them be > > applied during building 3) Remove applied modifications. See [3] > > for the mail originally sent by Russ. > > Er... I don't really understand how it works. > Just use debian/rules patch to patch, debian/rules reverse-patches to > remove the patches, and debian/rules binary to build? Did you read the links I've posted? Its described in detail, there. But to make it clear: This file is for other people then you, so that they have a chance to lookup how certain processes work with your package. E.g. for the security team to read up, what they need to do, to get a fully patched source, create new pages, remove patches. That is that people who usually don't maintain your package and probably usually use other methods (e.g. quilt and debhelper instead of CDBS and patchsys) have a chance to update your package (for example due to a security issue). Whats missing from your file is a documented way to create a new patch. > I included the one you made, although upstream may change it at any > time. Well, thats true for most of the upstreams :-) Basically what you then do is adapting the package. Hopefully watch files will at some point in the future be cared for outside of the package at a central location this will ease its maintainance. > Compat is now 5. Yeah right, but you missed the depend in debian/control. > It may be a bit better, now. It would be better to make two makefiles of the first one. So that every patch is for exactly one change. BTW. please do not forget to forward the patches upstream. The proposed seperating into two pages also makes it easier for you if upstream integrates only one part of the patch. > I think Recommends are adequate. This packages aren't required to run > bluemindo, but they are required to use several features. That sounds reasonable. But there is still a question that you should clear: Are those features really common to the usual user of the software? Is it someone one usually would expect? If yes, then Recommends is fine
RFS: nemesis (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:1.4-1 of my package "nemesis". It builds these binary packages: nemesis- TCP/IP Packet Injection Suite The upload would fix these bugs: 405459, 483700 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/nemesis - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards William Vera -- William Vera <[EMAIL PROTECTED]> PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
