Re: FYI: GNAT 3.15p has been released
Jon Ward wrote: On Sun, Nov 24, 2002 at 08:47:35PM +0100, J?r?me Marant wrote: This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. I've been working on it this weekend - I've retitled the bugs for gnat and gnat-doc to ITA. As I type, my old SparcStation 4 is chugging away with a compile of it. Good! Bear with me, these are my first Debian packages... Sponsors will check the packages anyway. Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ganhe uma boa grana simplesmente por estar online!!!
Ganhe uma boa grana simplesmente por estar online cadastre-se agora mesmo é grátis e sem nenhum investimento http://www.ganhosdanet.hpg.ig.com.br/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Library help needed
Hi there! I am in the position to have to maintain a library package from a source where the upstream maintainer isn't familar with libtool and SONAME. Unfortunately me neither. I have read through the libtool-doc info pages about it and read the Library Packaging Guide, but still have no real clue how to tackle this. This is my first and only library package so I am not that familar with handling of these... Here is how it goes: The package in question is metakit. The upstream maintainer doesn't add -version-info but lately uses -avoid-version (with previous source he hasn't used neither one, so the files were always .so.0.0.0). I may have made a mistake by adding a -version-info with a SOVERSION of 1:0:0 for my first upload, but that can't be taken back now. I tried to talk to the upstream maintainer about the problem and he said he doesn't have a clue about libtool neither. So, what shall I do? Shall I increase the SOVERSION for Debian by myself, for afaict each upstream source _did_ change the interface. I am quite puzzled, and there passed some upstream versions by that I wasn't able to upload because of that yet. Fortunately the library isn't that intensively used, but I like to do it right[tm]. And especially I guess the problem to build the python bindings solved in the later upstream releases, so I guess it would be nice to have that, too. Ah yes. About splitting the package: It can produce usual c bindings, and tcl and python bindings. Shall I do a seperate package for each of them? And an additional -doc package? Or doesn't it hurt if I put them all into the same package (and the -doc things into the -dev package)? I like the idea of having specialized packages but on the other hand it always should be a matter of how small they would get. I dislike having much small sized packages rather than having some medium sized ones Thank you very much, your sugguestions are appreciated. It would be nice to Cc: me on replies because I track the list only through the web archive. So long, Alfie -- Hi Leite! Ich bin neuer Chello Kunde - habe gehört, dass man hier Filme und Sitcoms runterladen kann, die ein anderer Kunde von Chelle am Server hat! Nur wieee Datei speichern unter... -- Bernhard Steiner, [EMAIL PROTECTED] msg07986/pgp0.pgp Description: PGP signature
Request for Sponsor: [libnet-easytcp-perl]
Hello, Am looking for a sponsor for my package `libnet-easytcp-perl' Debian related files can be found here: http://madhu.homelinux.org/debian/libnet-easytcp-perl/ Package: libnet-easytcp-perl Version: 0.17-1 Section: interpreters Priority: optional Architecture: all Depends: perl (= 5.6.0-16) Installed-Size: 118 Maintainer: Shiju p. Nair [EMAIL PROTECTED] Description: Easily create secure, bandwidth-friendly TCP/IP clients and servers This class allows you to easily create TCP/IP clients and servers and provides an OO interface to manage the connection(s). This allows you to concentrate on the applica- tion rather than on the transport. . - One easy module to create both clients and servers - Object Oriented interface - Event-based callbacks in server mode - Internal protocol to take care of all the common transport problems - Transparent encryption - Transparent compressi -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Misc questions: add image to package, man page for cgi script, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frédéric, On Mon, Nov 25, 2002 at 11:35:26PM +1100, Frederic Schutz wrote: 1) I'd like to add a binary file to the upstream source (an image, so that all images are available locally and no Internet connection is needed). Obviously, the diff file doesn't like binaries, so what is the best way to do it ? [Currently, I added the image as a uuencoded file, with a Build-Depends: sharutils (sharutils contains uudecode) and a line in debian/rules that decodes it at build time] You have to use uuencode/uudecode. There is also a Perl script for this. This should answer your question: http://lists.debian.org/debian-mentors/2002/debian-mentors-200203/msg00027.html IIRC, theres development to enable binary diffs for the debian package utils, but I dont remember the thread anymore. 2) Should I write a man page for a CGI script ? If yes, could someone point me to an example of such a page ? No, there is no rule that one must have a man page for CGI scripts. Usually I make a note in the package description, in README or in README.Debian (whatever seems appropriate) that theres a CGI script available. 3) The package contains a Perl script that can be used either as a cgi-bin and on the command line [it is not the same script than in 2) and I already wrote a man page for the command line version]. I can install it in either /usr/lib/cgi-bin or /usr/bin and put a symbolic link in the other directory. What is the best way to do it ? I would think that I should put it in the cgi-bin directory, since the web server (Apache) will probably not follow a symlink, while this is not a problem for a command. Any other thought on the question ? As you said, you should not have symlinks pointing outside of /usr/lib/cgi-bin. I think there are two options: a) symlink from /usr/bin/foo to /usr/lib/cgi-bin/foo b) Make a cgi-only version and a commandline-only version of the script and put them in the proper dir. Because I'm lazy, I'd prefer a). Cheers, Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE94iXceBwlBDLsbz4RAjEOAKC1pFcMFhj+Pvag8tRHYKEgbagssQCeNh2s YaxPrleHItp/r6AuDx2F+nk= =gu+8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using gcc/g++-3.2 as default compiler
If you use g++ 3.2, all c++ libraries you link with should also be compiled by gcc 3.2 Hello all, I am trying to build a new version of one of my packages, as upstream has ported it to gcc/g++-3.2 and KDE3. It would be nice to have the kinks ironed out before the transition actually happens in sid, I think. I am wondering if anyone has any good method for switching the default compiler. I am using a pbuilder chroot, and so I log in, and then switch the symlinks (gcc, g++, gcov, and cpp) to point to the 3.2 versions. For now, the build is failing. In order to help sort it out, are there any other links I should be switching? Some other (smarter?) way to do this? It builds fine before I mess with any of the links, or set environment variables (CC, CXX, CPP), so I'm not convinced that it's a code problem, although it may be - I know there are many incompatibilities between the two versions. TIA, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FYI: GNAT 3.15p has been released
Jon Ward wrote: On Sun, Nov 24, 2002 at 08:47:35PM +0100, J?r?me Marant wrote: This is just a reminder that GNAT 3.15p has been released. I think that it is far more stable that the version from GCC so it would be nice to make it available to Ada coders. I recall that some people were interested in taking it over. I've been working on it this weekend - I've retitled the bugs for gnat and gnat-doc to ITA. As I type, my old SparcStation 4 is chugging away with a compile of it. Good! Bear with me, these are my first Debian packages... Sponsors will check the packages anyway. Cheers,
Ganhe uma boa grana simplesmente por estar online!!!
Ganhe uma boa grana simplesmente por estar online cadastre-se agora mesmo é grátis e sem nenhum investimento http://www.ganhosdanet.hpg.ig.com.br/
Library help needed
Hi there! I am in the position to have to maintain a library package from a source where the upstream maintainer isn't familar with libtool and SONAME. Unfortunately me neither. I have read through the libtool-doc info pages about it and read the Library Packaging Guide, but still have no real clue how to tackle this. This is my first and only library package so I am not that familar with handling of these... Here is how it goes: The package in question is metakit. The upstream maintainer doesn't add -version-info but lately uses -avoid-version (with previous source he hasn't used neither one, so the files were always .so.0.0.0). I may have made a mistake by adding a -version-info with a SOVERSION of 1:0:0 for my first upload, but that can't be taken back now. I tried to talk to the upstream maintainer about the problem and he said he doesn't have a clue about libtool neither. So, what shall I do? Shall I increase the SOVERSION for Debian by myself, for afaict each upstream source _did_ change the interface. I am quite puzzled, and there passed some upstream versions by that I wasn't able to upload because of that yet. Fortunately the library isn't that intensively used, but I like to do it right[tm]. And especially I guess the problem to build the python bindings solved in the later upstream releases, so I guess it would be nice to have that, too. Ah yes. About splitting the package: It can produce usual c bindings, and tcl and python bindings. Shall I do a seperate package for each of them? And an additional -doc package? Or doesn't it hurt if I put them all into the same package (and the -doc things into the -dev package)? I like the idea of having specialized packages but on the other hand it always should be a matter of how small they would get. I dislike having much small sized packages rather than having some medium sized ones Thank you very much, your sugguestions are appreciated. It would be nice to Cc: me on replies because I track the list only through the web archive. So long, Alfie -- Hi Leite! Ich bin neuer Chello Kunde - habe gehört, dass man hier Filme und Sitcoms runterladen kann, die ein anderer Kunde von Chelle am Server hat! Nur wieee Datei speichern unter... -- Bernhard Steiner, [EMAIL PROTECTED] pgpur48ArMUUT.pgp Description: PGP signature
Request for Sponsor: [libnet-easytcp-perl]
Hello, Am looking for a sponsor for my package `libnet-easytcp-perl' Debian related files can be found here: http://madhu.homelinux.org/debian/libnet-easytcp-perl/ Package: libnet-easytcp-perl Version: 0.17-1 Section: interpreters Priority: optional Architecture: all Depends: perl (= 5.6.0-16) Installed-Size: 118 Maintainer: Shiju p. Nair [EMAIL PROTECTED] Description: Easily create secure, bandwidth-friendly TCP/IP clients and servers This class allows you to easily create TCP/IP clients and servers and provides an OO interface to manage the connection(s). This allows you to concentrate on the applica- tion rather than on the transport. . - One easy module to create both clients and servers - Object Oriented interface - Event-based callbacks in server mode - Internal protocol to take care of all the common transport problems - Transparent encryption - Transparent compressi --
Misc questions: add image to package, man page for cgi script, etc
[please cc: me if possible] Hi everyone, I'm currently packaging the w3c-markup-validator (http://validator.w3.org:8001) and I have a few questions -- nothing that stopped me while doing the package, but I'd just like to make sure I used the best practice... 1) I'd like to add a binary file to the upstream source (an image, so that all images are available locally and no Internet connection is needed). Obviously, the diff file doesn't like binaries, so what is the best way to do it ? [Currently, I added the image as a uuencoded file, with a Build-Depends: sharutils (sharutils contains uudecode) and a line in debian/rules that decodes it at build time] 2) Should I write a man page for a CGI script ? If yes, could someone point me to an example of such a page ? 3) The package contains a Perl script that can be used either as a cgi-bin and on the command line [it is not the same script than in 2) and I already wrote a man page for the command line version]. I can install it in either /usr/lib/cgi-bin or /usr/bin and put a symbolic link in the other directory. What is the best way to do it ? I would think that I should put it in the cgi-bin directory, since the web server (Apache) will probably not follow a symlink, while this is not a problem for a command. Any other thought on the question ? That's it for the moment; I'm pretty sure I'll find other questions to ask but any help/confirmation on these points would already be greatly appreciated. Thanks in advance ! Frédéric
Re: Misc questions: add image to package, man page for cgi script, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frédéric, On Mon, Nov 25, 2002 at 11:35:26PM +1100, Frederic Schutz wrote: 1) I'd like to add a binary file to the upstream source (an image, so that all images are available locally and no Internet connection is needed). Obviously, the diff file doesn't like binaries, so what is the best way to do it ? [Currently, I added the image as a uuencoded file, with a Build-Depends: sharutils (sharutils contains uudecode) and a line in debian/rules that decodes it at build time] You have to use uuencode/uudecode. There is also a Perl script for this. This should answer your question: http://lists.debian.org/debian-mentors/2002/debian-mentors-200203/msg00027.html IIRC, theres development to enable binary diffs for the debian package utils, but I dont remember the thread anymore. 2) Should I write a man page for a CGI script ? If yes, could someone point me to an example of such a page ? No, there is no rule that one must have a man page for CGI scripts. Usually I make a note in the package description, in README or in README.Debian (whatever seems appropriate) that theres a CGI script available. 3) The package contains a Perl script that can be used either as a cgi-bin and on the command line [it is not the same script than in 2) and I already wrote a man page for the command line version]. I can install it in either /usr/lib/cgi-bin or /usr/bin and put a symbolic link in the other directory. What is the best way to do it ? I would think that I should put it in the cgi-bin directory, since the web server (Apache) will probably not follow a symlink, while this is not a problem for a command. Any other thought on the question ? As you said, you should not have symlinks pointing outside of /usr/lib/cgi-bin. I think there are two options: a) symlink from /usr/bin/foo to /usr/lib/cgi-bin/foo b) Make a cgi-only version and a commandline-only version of the script and put them in the proper dir. Because I'm lazy, I'd prefer a). Cheers, Bastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE94iXceBwlBDLsbz4RAjEOAKC1pFcMFhj+Pvag8tRHYKEgbagssQCeNh2s YaxPrleHItp/r6AuDx2F+nk= =gu+8 -END PGP SIGNATURE-
Re: Using gcc/g++-3.2 as default compiler
If you use g++ 3.2, all c++ libraries you link with should also be compiled by gcc 3.2 Hello all, I am trying to build a new version of one of my packages, as upstream has ported it to gcc/g++-3.2 and KDE3. It would be nice to have the kinks ironed out before the transition actually happens in sid, I think. I am wondering if anyone has any good method for switching the default compiler. I am using a pbuilder chroot, and so I log in, and then switch the symlinks (gcc, g++, gcov, and cpp) to point to the 3.2 versions. For now, the build is failing. In order to help sort it out, are there any other links I should be switching? Some other (smarter?) way to do this? It builds fine before I mess with any of the links, or set environment variables (CC, CXX, CPP), so I'm not convinced that it's a code problem, although it may be - I know there are many incompatibilities between the two versions. TIA,
Re: RFC: Sponsor request convention
On 24 Nov 2002, Rob Bradford wrote: I think it would be nice to achieve some kind of convention on the format of messages requesting sponsors for packages. Not a bad idea, on the whole. Feel like writing this up in a webpage somewhere, sort of a Requesting Sponsorship HOWTO. That way, anyone who does it any other way can be pointed in the right direction. And in the body several pseudo-headers, containing information such as a long description, the version, homepage and location of the source packages for your proposed version. Including NM status here (where applicable) would also be beneficial. GPG key ID, too. I'm leaning towards only accepting packages for sponsorship which are properly signed. Best to get them into the habit early. g I think it would also be relevent to forbid cross posting into debian-devel, specific lists such as debian-python, debian-gtk-gnome etc would work. Requests for sponsorship should be limited to debian-mentors and any specific mailing lists which deal with the technology of the package. Cross-posting to debian-devel is explicitly forbidden. I don't know if we can actually say forbidden in something like this, but we need to make it fairly strong that d-devel is not for sponsorship requests. - Matt
