pptpconfig php with pcntl support
Hello mentors, I would like to ask the following: really nice gtk-php app which deserves to be included in debian: http://quozl.netrek.org/pptp/pptpconfig/ pptpconfig needs a php interpreter built with --enable-pcntl (it calls functions like: pcntl_signal(), pcntl_wifexited(), pcntl_wexitstatus(), pcntl_wifsignaled(), pcntl_wtermsig(), pcntl_wifstopped(), pcntl_wstopsig() for process signalling). OK it installs another interpreter with pcntl support enabled and uses it as well. Works well. Now if pptpconfig wants to hit the official debian archive the following options occur: * things remain the way thay are now - with another php interpreter with pcntl support installed * enable pcntl support in the official debian php packages - I have been told that it is insecure for serving web content. What are the exact reasons behind that ? * figure out a way to replace the current process signalling without using pcntl_* functions, but the support enabled in the official debian php packages. Unfortunately looking at php docs it seems not to be possible. What is the best way to resolv the situation ? Thanks. -- pub 4096R/0E4BD0AB 2003-03-18 danchev.fccf.net/key pgp.mit.edu fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB pgpwlqX3lfSlT.pgp Description: PGP signature
Re: pptpconfig php with pcntl support
On Tue, Apr 26, 2005 at 11:56:57AM +0300, George Danchev wrote: I would like to ask the following: really nice gtk-php app which deserves to be included in debian: http://quozl.netrek.org/pptp/pptpconfig/ pptpconfig needs a php interpreter built with --enable-pcntl (it calls functions like: pcntl_signal(), pcntl_wifexited(), pcntl_wexitstatus(), pcntl_wifsignaled(), pcntl_wtermsig(), pcntl_wifstopped(), pcntl_wstopsig() for process signalling). OK it installs another interpreter with pcntl support enabled and uses it as well. Works well. Now if pptpconfig wants to hit the official debian archive the following options occur: * things remain the way thay are now - with another php interpreter with pcntl support installed * enable pcntl support in the official debian php packages - I have been told that it is insecure for serving web content. What are the exact reasons behind that ? * figure out a way to replace the current process signalling without using pcntl_* functions, but the support enabled in the official debian php packages. Unfortunately looking at php docs it seems not to be possible. What is the best way to resolv the situation ? Thanks. * rewrite the app using a language that doesn't suck for GUIs -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RFS : connect : establish ssh connection over socks 4/5 proxies (alt suggested name ssh-connect-proxy)
On 4/25/05, RzR www.rzr.online.fr [EMAIL PROTECTED] wrote: I used report bug to report an ITP, but another ITP from sonia crossed mine (one of those both needs to be closed) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306268 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294943 She filed it first. I suggest that you contact her and see if she's still interested in packaging it or not. -- Carlos Laviola [EMAIL PROTECTED]
RFS: ttf-mph-2b-damase -- font with ranges from the latest version of unicode
Hi all, (I'm not subscribed, please CC me and the ITP - MFT set) Package name: ttf-mph-2b-damase Upstream Author : Mark Williamson [EMAIL PROTECTED] Upstream URL: http://fixedsys.org/~node_ue/fonts/ License : Public Domain ITP : http://bugs.debian.org/306290 Package : deb-src http://mentors.debian.net/debian unstable main http://mentors.debian.net/debian/pool/main/t/ttf-mph-2b-damase/ Description : font with ranges from the latest version of unicode MPH 2B Damase is a SuperUnicode font, including some ranges in Plane 1 and some ranges added only in the latest release of the Unicode standard, 4.1 (such as Tifinagh, Kharosthi, hPhags-pa, Old Persian Cuneiform etc). Upstream has given blessings for this to be in debian. Better short/long descriptions very welcome. Lintian/Linda clean. -- bye, pabs http://pabs.zip.to signature.asc Description: This is a digitally signed message part
Re: Shared library concern
Franois-Denis Gonthier [EMAIL PROTECTED] writes: Did you run lintian with -i? Lintian can explain its tags on request. It's such a pity this seems to be such an unknown feature... Thank you! This was a precious hint. I realise I was a bit off on this SONAME thing. Reading the guides and policy manual also made me realise this package needs some more work. I'll be reading on dbs and dpatch today. Maybe you want to have a look at CDBS as well. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com Say NO to Software Patents! -- http://petition.eurolinux.org/
RFS: gxine 0.4.4 (source NMU)
Re. http://sourceforge.net/mailarchive/message.php?msg_id=11562029, I've prepared an NMU of gxine which fixes the RC bug and several other bugs which are present in 0.4.1. There are a few small packaging changes which shouldn't cause any problems; in particular, gnome-xine is dropped since it's not present outside sid (within Debian). gxine-0.4.4.tar.gz: URL:http://prdownloads.sourceforge.net/xine/gxine-0.4.4.tar.gz?download (yes, I just released it...) .diff.gz, .dsc: URL:http://zap.tartarus.org/~ds/debian/. I can also prepare a .diff.gz and .dsc for an NMU of xine-lib (libxine1, libxine-dev) if it would help. An upload is needed to close a security hole (see URL:http://xinehq.de/index.php/security/XSA-2004-8; bug 305343). -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Retrocomputing: a PC card in a Risc PC Don't overuse exclamation marks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gxine 0.4.4 (source NMU)
On Tue, Apr 26, 2005 at 10:28:03PM +0100, Darren Salt wrote: Re. http://sourceforge.net/mailarchive/message.php?msg_id=11562029, I've prepared an NMU of gxine which fixes the RC bug and several other bugs which are present in 0.4.1. There are a few small packaging changes which shouldn't cause any problems; in particular, gnome-xine is dropped since it's not present outside sid (within Debian). Sponsoring an NMU is a really, really bad idea. It kind of mucks up the chain of control more than a little bit. I'd suggest that you make appropriate notations in the bug logs for the various bugs that you close with the new upstream release, and then notify the maintainer directly, as well as the QA (debian-qa@lists.debian.org) and security ([EMAIL PROTECTED]) teams (because of #305343) and let them take care of it. - Matt signature.asc Description: Digital signature
Re: RFS: gxine 0.4.4 (source NMU)
I demand that Matthew Palmer may or may not have written... On Tue, Apr 26, 2005 at 10:28:03PM +0100, Darren Salt wrote: Re. http://sourceforge.net/mailarchive/message.php?msg_id=11562029, I've prepared an NMU of gxine which fixes the RC bug and several other bugs which are present in 0.4.1. There are a few small packaging changes which shouldn't cause any problems; in particular, gnome-xine is dropped since it's not present outside sid (within Debian). Sponsoring an NMU is a really, really bad idea. It kind of mucks up the chain of control more than a little bit. I'd suggest that you make appropriate notations in the bug logs for the various bugs that you close with the new upstream release, and then notify the maintainer directly, Most of it is in CVS (tag gxine-0_4_4-release); the bugs mentioned there are already tagged fixed-upstream. I've forgotten to mention in the changelog that bug 305106 is to be closed - I'll close this manually if necessary - and bug 295184, IMO, shouldn't be closed yet because only the build-dep part has been applied to 0.4.4. I applied the rest of it to CVS HEAD only. as well as the QA (debian-qa@lists.debian.org) and security ([EMAIL PROTECTED]) teams (because of #305343) That affects xine-lib. The relevant bug here is 289412/295344, which isn't security-critical; this message is CCed accordingly. (I'll see any responses if they're in -mentors or CCed to me.) and let them take care of it. Whether it's uploaded with my name or a DD's name in the changelog entry for 0.4.4, I don't particularly mind. It's probably easiest to start with my .diff.gz or the debian directory from CVS, though. -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/progs.linux.html OS/2? Where's the other half? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sitecopy
Philipp: Following up on my earlier post, upstream has asked what do you want me to do about that old debian directory?, and I asked him to remove it. Although it's still in place for the 0.15.1 version that he released on Sunday (May 24), it'll be gone from subsequent releases. Reed Philipp Kern wrote: On 23 Apr 2005, at 05:45, Reed Snellenberger wrote: Files are available at: http://home.houston.rr.com/snellenberger/debian/sitecopy/ Do you know why there is an outdated debian/ subdirectory in the upstream tarball? And if the current version of sitecopy does not work with the old xsitecopy I would suggest a ``Conflicts: xsitecopy'' instead of the versioned one. Kind regards, Philipp Kern Debian Developer -- Reed Snellenberger GPG KeyID: 5A978843 rsnellenberger-at-houston.rr.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
build test
Hello, It seem that nobody has got interested in sponsoring AVInfo yet. Perhaps, my advertising was too pushing ;) Anyway, I have got a question I would like to ask. Is there any kind of testing buid system (maybe unofficial one), I mean something where I can upload my package to and try to compile it for platforms different from those I have access to (I can do it on i386 and on Sparc)? I do not mean pbuilder which I have installed locally. I mean something closer to a real Debian automatic build system. If there were such it would help a lot fighting against (possible) arch-related bugs. Just waiting and doing nothing does not seem very nice to me. Thanks, Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
