Re: RFS: msmtp, wmnetload, wmwifi
On Mon, 2003-11-24 at 20:26, Jess Mahan wrote: I made a lot of changes to my packages (Thanks BTW for all the helpfull comments from everyone. Can you please check them out now, and see if I did it right this time? deb http://digitalssg.net/debian/ stable main non-US deb-src http://digitalssg.net/debian/ stable main non-US [EMAIL PROTECTED]:~/projects/debian/msmtp% apt-get source msmtp Reading Package Lists... Done Building Dependency Tree... Done Need to get 206kB of source archives. Get:1 http://digitalssg.net stable/non-US msmtp 0.6.2-1 (dsc) [621B] Err http://digitalssg.net stable/non-US msmtp 0.6.2-1 (tar) 403 Forbidden Get:2 http://digitalssg.net stable/non-US msmtp 0.6.2-1 (diff) [95.0kB] Fetched 95.7kB in 3s (28.4kB/s) Failed to fetch http://digitalssg.net/debian/dists/stable/non-US/source/msmtp_0.6.2.orig.tar.gz 403 Forbidden E: Failed to fetch some archives. On Thu, Nov 20, 2003 at 11:57:28AM -0600, Joe Wreschnig wrote: Okay, the URL is working for me now. On Wed, 2003-11-19 at 16:53, Jess Mahan wrote: Hi, I would like to get a sponsor. I am new to sponsorship/manitaining although I am not new to Debian or Linux. Debian is my favorite Linux distribution and I am excited about contributing to it. Below are the packages I am requesting sponsorship for: msmtp (0.6.1 0.6.2 ) - An SMTP plugin for Mutt and probably other MUAs. - With your build-dependencies, the result is a binary linked against OpenSSL. This is a violation of copyright to distribute, since the OpenSSL license and GPL are not compatible. The source seems to have GNU TLS support in it; you should make sure it uses that (via ./configure) instead of OpenSSL. Unfortunatly, I cannot get it to build with gnutls3 on woddy, so i created the package anyway, and made a non-US section on my repository. This isn't a US vs. non-US issue. Distributing a GPLd program linked to OpenSSL is copyright infringement; it just plain can't be done without permission from the upstream author(s). You could either talk to the upstream authors (they'd probably be amenable to an exception to the GPL for OpenSSL), but since it does have GNU TLS support, I personally wouldn't recommend weakening the copyleft by using such an exception. I did however get it to build and link under debian/testing with lingnutls7. Packages uploaded to the archive must be compiled against unstable. Your sponsor (e.g. me) will be the person actually building it, but it's your job to make sure that it works as such. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: RFS: loop-aes (#111167)
#include hallo.h * Max Vozeler [Fri, Nov 21 2003, 05:54:39AM]: * URL : http://loop-aes.sourceforge.net * License : GPL Description : AES-encryption loopback Linux kernel module Bugs: - source depends on utils, why? No other -source package works that way. - document properly that your package does NOT build with kernel-headers - binary-modules is hosed: mv /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23 \ /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23-rc3 mv: cannot stat `/usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23': No such file or directory make[1]: *** [binary-modules] Error 1 make[1]: Leaving directory `/usr/src/modules/loop-aes' make: *** [kdist_image] Error 2 MfG, Eduard. -- Die Liebe ist immer eine Art Wahnsinn, mehr oder minder schön. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: loop-aes (#111167)
#include hallo.h * Eduard Bloch [Tue, Nov 25 2003, 07:37:53AM]: - source depends on utils, why? No other -source package works that way. - document properly that your package does NOT build with kernel-headers - binary-modules is hosed: PS: ... and you use old dh_make templates which silently ignore KPKG_DEST_DIR. Please look at the alsa package or module-assistant's templates for example. MfG, Eduard. -- Die Welt hat genug für jedermanns Bedürfnisse, aber nicht genug für jedermanns Gier. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Best Way to Fix Package Icon
The package I am working on has an existing icon neatly installed by the upstream Makefile; the problem is it is a 48x48 png instead of a 32x32 xpm as Debian Policy requires. The Makefile automatically installs this png as: /usr/share/pixmaps/gmasqdialer-icon.png I have modified it to the right size and created a new image: gmasqdialer-icon-debian.xpm I can then use the build scripts to copy it to the appropriate directory. However, I need to get rid of the old icon file. What is the best way to fix this? Modify the Makefile to not install it? Or is it best to keep my fingers out of the source for the program as much as possible and delete it with the build scripts? If I modify the Makefile I could easily have it install the 'fixed' icon instead. Is that the best solution perhaps? -- Daniel E. Markle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best Way to Fix Package Icon
On Thu, Nov 27, 2003 at 12:11:39AM -0500, Daniel E. Markle wrote: I can then use the build scripts to copy it to the appropriate directory. However, I need to get rid of the old icon file. What is the best way to fix this? Modify the Makefile to not install it? Or is it best to keep my fingers out of the source for the program as much as possible and delete it with the build scripts? If I modify the Makefile I could easily have it install the 'fixed' icon instead. Is that the best solution perhaps? After the makefile installs the image, nuke it from within debian/rules. IMHO the best way because you don't mess with the upstream source quite as much. -- Joshua Kwan pgp0.pgp Description: PGP signature
executing scripts after receiving a fax
Hi, before the real start: This mail is sent to two mailing lists. [EMAIL PROTECTED] is the mgetty-mailinglist, debian-mentors a list for getting good ideas from within the Debian project; please send answers also to both lists (and there is no need to Cc me, as I'm subscribed to both lists). The goal of this mail is to get a framework to for handling incoming faxes by different scripts (see below), and constructing this framework in a way that it is usable inside and outside debian. I don't want to do anything that would break this on any OS, but I also don't want to do anything that would it make hard to follow debians policies. Now to content: After a new fax is received, currently a single file is executed, and (independent of that) mail sent to the one certain user (mostly to the system-administrator). I want to have a plug-able framework, where a lot of scripts can sit in, and get executed after a fax is received. This should also be scalable to receiving faxes at different phone numbers, and handling them different. My current proposal is to create scripts (sitting in @LIBDIR@) that could do the necessary transformations to a new fax, and to create a directory (in @CONFDIR@) that could contain symlinks or even (in more complex setups) small shell scripts that call the right script(s), and perhaps change some arguments to them, according to recipient number, ... After receiving a fax, the scripts are executed with something like run-parts (execute each script in lexical order in a given directory), and failure or success are logged. For the API I'm currently undecided. The one existing script get currently the some options via command line interface, and other via environment. It would be IMHO much easier if environment would be specified as the standard way to pass options (as this would it make _really_ easy to e.g. overwrite mail recipient addresses). Any opinion on this, and should I use a standard-prefix to variable names (e.g. RECEIVED_FAX_...)? We have (for all programms) at least the values of the senders number (via the phone), senders code (via fax protocol), recipients number, number of received pages, hangup code, and the pages. Some programms could also allow to override e.g. a recipients mail address, so they may have even more options. One last (but more easily) question is open: What programms should exist? Create a mail with the fax as png, a mail with pdf, a automatic print-out? Any more? I hope my proposal is clear, and would like to receive comments and suggestions on this. Thank you for your time for reading (and maybe even answering) my mail. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: msmtp, wmnetload, wmwifi
On Mon, 2003-11-24 at 20:26, Jess Mahan wrote: I made a lot of changes to my packages (Thanks BTW for all the helpfull comments from everyone. Can you please check them out now, and see if I did it right this time? deb http://digitalssg.net/debian/ stable main non-US deb-src http://digitalssg.net/debian/ stable main non-US [EMAIL PROTECTED]:~/projects/debian/msmtp% apt-get source msmtp Reading Package Lists... Done Building Dependency Tree... Done Need to get 206kB of source archives. Get:1 http://digitalssg.net stable/non-US msmtp 0.6.2-1 (dsc) [621B] Err http://digitalssg.net stable/non-US msmtp 0.6.2-1 (tar) 403 Forbidden Get:2 http://digitalssg.net stable/non-US msmtp 0.6.2-1 (diff) [95.0kB] Fetched 95.7kB in 3s (28.4kB/s) Failed to fetch http://digitalssg.net/debian/dists/stable/non-US/source/msmtp_0.6.2.orig.tar.gz 403 Forbidden E: Failed to fetch some archives. On Thu, Nov 20, 2003 at 11:57:28AM -0600, Joe Wreschnig wrote: Okay, the URL is working for me now. On Wed, 2003-11-19 at 16:53, Jess Mahan wrote: Hi, I would like to get a sponsor. I am new to sponsorship/manitaining although I am not new to Debian or Linux. Debian is my favorite Linux distribution and I am excited about contributing to it. Below are the packages I am requesting sponsorship for: msmtp (0.6.1 0.6.2 ) - An SMTP plugin for Mutt and probably other MUAs. - With your build-dependencies, the result is a binary linked against OpenSSL. This is a violation of copyright to distribute, since the OpenSSL license and GPL are not compatible. The source seems to have GNU TLS support in it; you should make sure it uses that (via ./configure) instead of OpenSSL. Unfortunatly, I cannot get it to build with gnutls3 on woddy, so i created the package anyway, and made a non-US section on my repository. This isn't a US vs. non-US issue. Distributing a GPLd program linked to OpenSSL is copyright infringement; it just plain can't be done without permission from the upstream author(s). You could either talk to the upstream authors (they'd probably be amenable to an exception to the GPL for OpenSSL), but since it does have GNU TLS support, I personally wouldn't recommend weakening the copyleft by using such an exception. I did however get it to build and link under debian/testing with lingnutls7. Packages uploaded to the archive must be compiled against unstable. Your sponsor (e.g. me) will be the person actually building it, but it's your job to make sure that it works as such. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: RFS: loop-aes (#111167)
#include hallo.h * Eduard Bloch [Tue, Nov 25 2003, 07:37:53AM]: - source depends on utils, why? No other -source package works that way. - document properly that your package does NOT build with kernel-headers - binary-modules is hosed: PS: ... and you use old dh_make templates which silently ignore KPKG_DEST_DIR. Please look at the alsa package or module-assistant's templates for example. MfG, Eduard. -- Die Welt hat genug für jedermanns Bedürfnisse, aber nicht genug für jedermanns Gier. -- Mahatma Gandhi
Re: RFS: loop-aes (#111167)
#include hallo.h * Max Vozeler [Fri, Nov 21 2003, 05:54:39AM]: * URL : http://loop-aes.sourceforge.net * License : GPL Description : AES-encryption loopback Linux kernel module Bugs: - source depends on utils, why? No other -source package works that way. - document properly that your package does NOT build with kernel-headers - binary-modules is hosed: mv /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23 \ /usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23-rc3 mv: cannot stat `/usr/src/modules/loop-aes/debian/tmp/lib/modules/2.4.23': No such file or directory make[1]: *** [binary-modules] Error 1 make[1]: Leaving directory `/usr/src/modules/loop-aes' make: *** [kdist_image] Error 2 MfG, Eduard. -- Die Liebe ist immer eine Art Wahnsinn, mehr oder minder schön.
Best Way to Fix Package Icon
The package I am working on has an existing icon neatly installed by the upstream Makefile; the problem is it is a 48x48 png instead of a 32x32 xpm as Debian Policy requires. The Makefile automatically installs this png as: /usr/share/pixmaps/gmasqdialer-icon.png I have modified it to the right size and created a new image: gmasqdialer-icon-debian.xpm I can then use the build scripts to copy it to the appropriate directory. However, I need to get rid of the old icon file. What is the best way to fix this? Modify the Makefile to not install it? Or is it best to keep my fingers out of the source for the program as much as possible and delete it with the build scripts? If I modify the Makefile I could easily have it install the 'fixed' icon instead. Is that the best solution perhaps? -- Daniel E. Markle
Re: Best Way to Fix Package Icon
On Thu, Nov 27, 2003 at 12:11:39AM -0500, Daniel E. Markle wrote: I can then use the build scripts to copy it to the appropriate directory. However, I need to get rid of the old icon file. What is the best way to fix this? Modify the Makefile to not install it? Or is it best to keep my fingers out of the source for the program as much as possible and delete it with the build scripts? If I modify the Makefile I could easily have it install the 'fixed' icon instead. Is that the best solution perhaps? After the makefile installs the image, nuke it from within debian/rules. IMHO the best way because you don't mess with the upstream source quite as much. -- Joshua Kwan pgpqbqRDOJUuA.pgp Description: PGP signature
executing scripts after receiving a fax
Hi, before the real start: This mail is sent to two mailing lists. [EMAIL PROTECTED] is the mgetty-mailinglist, debian-mentors a list for getting good ideas from within the Debian project; please send answers also to both lists (and there is no need to Cc me, as I'm subscribed to both lists). The goal of this mail is to get a framework to for handling incoming faxes by different scripts (see below), and constructing this framework in a way that it is usable inside and outside debian. I don't want to do anything that would break this on any OS, but I also don't want to do anything that would it make hard to follow debians policies. Now to content: After a new fax is received, currently a single file is executed, and (independent of that) mail sent to the one certain user (mostly to the system-administrator). I want to have a plug-able framework, where a lot of scripts can sit in, and get executed after a fax is received. This should also be scalable to receiving faxes at different phone numbers, and handling them different. My current proposal is to create scripts (sitting in @LIBDIR@) that could do the necessary transformations to a new fax, and to create a directory (in @CONFDIR@) that could contain symlinks or even (in more complex setups) small shell scripts that call the right script(s), and perhaps change some arguments to them, according to recipient number, ... After receiving a fax, the scripts are executed with something like run-parts (execute each script in lexical order in a given directory), and failure or success are logged. For the API I'm currently undecided. The one existing script get currently the some options via command line interface, and other via environment. It would be IMHO much easier if environment would be specified as the standard way to pass options (as this would it make _really_ easy to e.g. overwrite mail recipient addresses). Any opinion on this, and should I use a standard-prefix to variable names (e.g. RECEIVED_FAX_...)? We have (for all programms) at least the values of the senders number (via the phone), senders code (via fax protocol), recipients number, number of received pages, hangup code, and the pages. Some programms could also allow to override e.g. a recipients mail address, so they may have even more options. One last (but more easily) question is open: What programms should exist? Create a mail with the fax as png, a mail with pdf, a automatic print-out? Any more? I hope my proposal is clear, and would like to receive comments and suggestions on this. Thank you for your time for reading (and maybe even answering) my mail. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
