Bug#471279: dh-make-php: does not parse oci8 package correctly?

2008-03-21 Thread Vincent . McIntyre 



I have a suggestion for the dh-make-pecl script; could it not check for
unset or blank variables before charging on and making a mess in the
working directory, with directories named 'php--' and so on?
I've attached a patch that does what I would like to see, perhaps it
needs expanding and/or applying to dh-make-pear.
Perhaps it would be better to do the test in eval_package and return
a failure if variables that should always have a value are blank?

Though I suspect that your problem is fixed with a newer version of
dh-make-pecl, it sounds like a good idea to do some more error handling.
I'll see if your patch still make sense for newer verions.


The patch was against version 2.10, I may have stuffed up doing the
diff from the right part of my tree so it may not have the right
directories in the patch headers.

Cheers
Vince




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#471279: dh-make-php: does not parse oci8 package correctly?

2008-03-19 Thread Uwe Steinmann 
On Mon, Mar 17, 2008 at 01:58:09PM +1100, Vincent McIntyre wrote:
 Package: dh-make-php
 Version: 0.2.0
 Severity: normal
 Tags: patch
 thanks

 *** Please type your report below this line ***

 Hi,

 I am trying to use this package to build oci-8.2.4, viz:
   # dh-make-pecl --only 5 oci8

 This appears to download the tar file ok, but then it doesn't
 extract any information in the eval_package() function.
 For example the call to set the VERSION variable (set -x; set-v output):

 xsltproc --nonet --novalid --param Element /package/release/version
 ${PREFIX}/share/dh-make-php/xslt/common.xsl package.xml
  ++ xsltproc --nonet --novalid --param Element /package/release/version
 /usr/share/dh-make-php/xslt/common.xsl package.xml
   + VERSION=

 Could this be because the package.xml layout has changed?
 I'm no expert with xml parsing.
That could be and newer versions of dh-make-pecl are much more
robust when reading the package.xml file. Actually, they don't
use xsltproc anymore but a php script which used the pear class
for reading package.xml files. That class should handle all
possible flavours.

 I have a suggestion for the dh-make-pecl script; could it not check for
 unset or blank variables before charging on and making a mess in the
 working directory, with directories named 'php--' and so on?
 I've attached a patch that does what I would like to see, perhaps it
 needs expanding and/or applying to dh-make-pear.
 Perhaps it would be better to do the test in eval_package and return
 a failure if variables that should always have a value are blank?
Though I suspect that your problem is fixed with a newer version of
dh-make-pecl, it sounds like a good idea to do some more error handling.
I'll see if your patch still make sense for newer verions.

  Uwe



-- 
  MMK GmbH, Fleyer Str. 196, 58097 Hagen
  [EMAIL PROTECTED]
  Tel: 02331 840446Fax: 02331 843920


signature.asc
Description: Digital signature

Bug#471279: dh-make-php: does not parse oci8 package correctly?

2008-03-16 Thread Vincent McIntyre 

Package: dh-make-php
Version: 0.2.0
Severity: normal
Tags: patch
thanks

*** Please type your report below this line ***

Hi,

I am trying to use this package to build oci-8.2.4, viz:
  # dh-make-pecl --only 5 oci8

This appears to download the tar file ok, but then it doesn't
extract any information in the eval_package() function.
For example the call to set the VERSION variable (set -x; set-v output):

xsltproc --nonet --novalid --param Element /package/release/version
${PREFIX}/share/dh-make-php/xslt/common.xsl package.xml
 ++ xsltproc --nonet --novalid --param Element /package/release/version
/usr/share/dh-make-php/xslt/common.xsl package.xml
  + VERSION=

Could this be because the package.xml layout has changed?
I'm no expert with xml parsing.

I have a suggestion for the dh-make-pecl script; could it not check for
unset or blank variables before charging on and making a mess in the
working directory, with directories named 'php--' and so on?
I've attached a patch that does what I would like to see, perhaps it
needs expanding and/or applying to dh-make-pear.
Perhaps it would be better to do the test in eval_package and return
a failure if variables that should always have a value are blank?

Cheers
Vince

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)

Versions of packages dh-make-php depends on:
ii  cdbs  0.4.48 common build system for Debian pac
ii  php-pear  5.2.0-8+etch10 PEAR - PHP Extension and Applicati
ii  xmlstarlet1.0.1-2command line XML toolkit
ii  xsltproc  1.1.19-1   XSLT command line processor

dh-make-php recommends no packages.

-- no debconf information
--- usr/bin/dh-make-pecl.orig   2008-03-17 13:36:06.247865780 +1100
+++ usr/bin/dh-make-pecl2008-03-17 13:36:30.245468432 +1100
@@ -139,6 +139,16 @@
 # get information about package from package.xml
 eval_package
 
+# check we get something sensible
+for n in PHP_PKG_NAME VERSION OVERPACKAGENAME
+do
+eval v=\$$n
+[ X != X${v} ]  continue
+echo Variable '$n' is empty. Is the package name correct? Exiting.
+exit 1
+done
+
+
 if [ -n ${OVERPACKAGENAME} ]; then
mv ${PHP_PKG_NAME}-${VERSION} ${OVERPACKAGENAME}-${VERSION}
PHP_PKG_NAME=${OVERPACKAGENAME}