Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sun, Mar 11, 2007 at 01:56:42PM +0100, sean finney wrote: On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: I'm suggesting either. I'm happy to maintain the package seperately, but I intend to go through the differences between the versions and confirm that they are compatible, and steal anything good from the php-bundled version, so in effect I'd be doing both. I'd also have to track upstream PHP in case they add anything else to the library in the future. So maybe a PHP package team member might want to be a co-maintainer... okay, perhaps we can revisit this after you're done. if you decide to use the upstream version we can see how hard it is to build php against that instead of the bundled code. if you decide you want to use the php-bundled version, then we should probably just generate it from the php5 source package directly. i don't use this extension myself, so in any event it would be wise to find someone who does so we can test that it still works :) I've uploaded a test version to http://www.tbble.net/debian/xmlrpc-epi/. It's almost but not quite ready for sponsorship. I've not yet reinstalled pbuilder after my last server hard disk crash, so the build-depends aren't set yet. I suspect it's only missing libexpat-dev, but want to be sure. Also, I've not included the samples in the .debs. I'd like to get the compliance-tests run during build, but see below... I've also only built it on PowerPC; the pbuilder will be on i386, and if I have the time, I can get access to an AMD64 machine next week to do a test-build there. I did a file-by-file comparison with the PHP5 code, and the only differences I didn't bring across were whitespace, // = /* comment replacement and the xmlrpc_win32 header. If anyone's available to do a test-build against PHP5, that'd be great, otherwise it'll have to wait until I have the time, sometime this week, given a following wind. On a side-note, the server compliance tests fail, expecting an i4 tag but getting an int tag from the server, as well as large whitespace changes. The latter is prolly due to the much more recent expat library, the former is a mystery to me, but I suspect it is actually a change in the spec that post-dates the compliance-test creation. -- Paul TBBle Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpQZqIoDyf3G.pgp Description: PGP signature
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
OK, folks. You have the wrong bug report. #413968 is a bug to clamsmtp, and I REALLY don't think PHP is involved here. Please find the correct bug # and start sending emails there. Thank you, Chad (not a PHP guy) -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: I'm suggesting either. I'm happy to maintain the package seperately, but I intend to go through the differences between the versions and confirm that they are compatible, and steal anything good from the php-bundled version, so in effect I'd be doing both. I'd also have to track upstream PHP in case they add anything else to the library in the future. So maybe a PHP package team member might want to be a co-maintainer... okay, perhaps we can revisit this after you're done. if you decide to use the upstream version we can see how hard it is to build php against that instead of the bundled code. if you decide you want to use the php-bundled version, then we should probably just generate it from the php5 source package directly. i don't use this extension myself, so in any event it would be wise to find someone who does so we can test that it still works :) A quick poke around the Internet suggested that the only patches being made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but I haven't looked at the PHP-bundled version's changes yet, apart from verifying that the .h files match semanticly. did you check that visually, or did you use a utility like icheck? Hmm, I'd better check this now, all the files in the libxmlrpc directory carry the same copyright headers as the upstream xmlrpc-epi distribution (BSD-like), does the PHP license override them and prevent debundling? I'd like to keep the distinct package under its upstream license if possible, as it's very very permissive, and the seconde-life client is GPLd. if the files carry a copyright header i think that they override whatever the default PHP license might say, so i don't think it'd be a problem. sean signature.asc Description: This is a digitally signed message part
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sun, Mar 11, 2007 at 01:56:42PM +0100, sean finney wrote: On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: I'm suggesting either. I'm happy to maintain the package seperately, but I intend to go through the differences between the versions and confirm that they are compatible, and steal anything good from the php-bundled version, so in effect I'd be doing both. I'd also have to track upstream PHP in case they add anything else to the library in the future. So maybe a PHP package team member might want to be a co-maintainer... okay, perhaps we can revisit this after you're done. if you decide to use the upstream version we can see how hard it is to build php against that instead of the bundled code. if you decide you want to use the php-bundled version, then we should probably just generate it from the php5 source package directly. i don't use this extension myself, so in any event it would be wise to find someone who does so we can test that it still works :) Well, my plan was to effectively use the php5 version (since it's the main place the code's being actively used) but treat it as the upstream version with patches. If the package was generated straight out of the PHP source, it'd miss the samples and tests included in the upstream tarball. (Not that I've run the tests myself yet, the first roll of the package was pretty quick 'n' dirty.) A quick poke around the Internet suggested that the only patches being made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but I haven't looked at the PHP-bundled version's changes yet, apart from verifying that the .h files match semanticly. did you check that visually, or did you use a utility like icheck? Visually: [EMAIL PROTECTED]:~/code/php/php5-5.2.0/ext/xmlrpc/libxmlrpc$ for d in *.h; do diff ~/code/xmlrpcepi/build/xmlrpc-epi-0.51/src/$d $d; done 79,80c79,80 intQ_Iter_Put(q_iter qi, void* data); // not read only! here for completeness. void* Q_Iter_Del(queue *q, q_iter iter); // not read only! here for completeness. --- intQ_Iter_Put(q_iter qi, void* data); /* not read only! here for completeness. */ void* Q_Iter_Del(queue *q, q_iter iter); /* not read only! here for completeness. */ 161c161 xml_element* xml_elem_new(); --- xml_element* xml_elem_new(void); 43a44,48 /* allow version to be specified via compile line define */ #ifndef XMLRPC_LIB_VERSION #define XMLRPC_LIB_VERSION 0.51 #endif 48c53 #define XMLRPC_VERSION_STR xmlrpc-epi v. VERSION --- #define XMLRPC_VERSION_STR xmlrpc-epi v. XMLRPC_LIB_VERSION 302c307 XMLRPC_CASE XMLRPC_GetDefaultIdCase(); --- XMLRPC_CASE XMLRPC_GetDefaultIdCase(void); 304c309 XMLRPC_CASE_COMPARISON XMLRPC_GetDefaultIdCaseComparison(); --- XMLRPC_CASE_COMPARISON XMLRPC_GetDefaultIdCaseComparison(void); 326c331 XMLRPC_VALUE XMLRPC_CreateValueEmpty(); --- XMLRPC_VALUE XMLRPC_CreateValueEmpty(void); 376c381 XMLRPC_REQUEST XMLRPC_RequestNew(); --- XMLRPC_REQUEST XMLRPC_RequestNew(void); 386,387c391,392 XMLRPC_SERVER XMLRPC_ServerCreate(); XMLRPC_SERVER XMLRPC_GetGlobalServer(); /* better to use XMLRPC_ServerCreate if you can */ --- XMLRPC_SERVER XMLRPC_ServerCreate(void); XMLRPC_SERVER XMLRPC_GetGlobalServer(void); /* better to use XMLRPC_ServerCreate if you can */ 407c412 const char* XMLRPC_GetVersionString(); --- const char* XMLRPC_GetVersionString(void); diff: /home/tbble/code/xmlrpcepi/build/xmlrpc-epi-0.51/src/xmlrpc_win32.h: No such file or directory -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpZx4m3Z1NLe.pgp Description: PGP signature
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
hi paul, On Sun, 2007-03-11 at 03:05 +1100, Paul TBBle Hampson wrote: Would there be any interest in having PHP5 link its xmlrpc extension against a distinct library packaging of xmlrpc-epi? (ie. to avoid the situation which once existed for zlib being statically compiled into various other packages, causing security headaches...) just to clarify, are you proposing that php link against an externally provided xmlrpc-epi library, or are you proposing that php provide its bundled version *as* the xmlrpc-epi library for other apps to use? i'm fairly open to both ideas though i think the former sounds better than the latter, assuming there are no api/abi differences. also, are you volunteering to do the packaging? :) sean signature.asc Description: This is a digitally signed message part
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
On Sat, Mar 10, 2007 at 06:19:09PM +0100, sean finney wrote: hi paul, On Sun, 2007-03-11 at 03:05 +1100, Paul TBBle Hampson wrote: Would there be any interest in having PHP5 link its xmlrpc extension against a distinct library packaging of xmlrpc-epi? (ie. to avoid the situation which once existed for zlib being statically compiled into various other packages, causing security headaches...) just to clarify, are you proposing that php link against an externally provided xmlrpc-epi library, or are you proposing that php provide its bundled version *as* the xmlrpc-epi library for other apps to use? i'm fairly open to both ideas though i think the former sounds better than the latter, assuming there are no api/abi differences. also, are you volunteering to do the packaging? :) I'm suggesting either. I'm happy to maintain the package seperately, but I intend to go through the differences between the versions and confirm that they are compatible, and steal anything good from the php-bundled version, so in effect I'd be doing both. I'd also have to track upstream PHP in case they add anything else to the library in the future. So maybe a PHP package team member might want to be a co-maintainer... A quick poke around the Internet suggested that the only patches being made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but I haven't looked at the PHP-bundled version's changes yet, apart from verifying that the .h files match semanticly. Hmm, I'd better check this now, all the files in the libxmlrpc directory carry the same copyright headers as the upstream xmlrpc-epi distribution (BSD-like), does the PHP license override them and prevent debundling? I'd like to keep the distinct package under its upstream license if possible, as it's very very permissive, and the seconde-life client is GPLd. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp7UCgOsxIxb.pgp Description: PGP signature
