kai_mactane: (Default)

This is largely a bug-fix release. Tom Clift, of PaperCut print management software, kindly informed me of a few installation issues that my own tests didn’t find. The profusion of configuration options in PHP can make testing everything on a single server quite difficult.

This would be a good time for me to mention that I have the utmost respect for QA people. They deal with all sorts of minutiae that I am really glad not to have to handle, and I’m really glad they’re around. That said, I am not a QA person… and so I occasionally miss the sorts of stuff they’d catch.

  1. It turns out Hummingbird depends on the CLI version of PHP, and the CGI version will not suffice. This requirement is now listed in the appropriate section of the Hummingbird page.
  2. Not all PHP installations have output buffering turned on by default. The latest version of Hummingbird takes account for this.
  3. Various problems that can occur with the data cache file are also now reported more gracefully.

Again, my thanks to Tom Clift for some very useful patches!

You can get the latest version of Hummingbird from the Hummingbird page on my site.

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

If you haven’t been getting as much email as usual this past week, the culprit may be SpamAssassin. It turns out that SpamAssassin 3.2.5 (the current version, released in June of 2008) has a Year 2010 Bug.

The problem lies in the core configuration file 72_active.cf, which contains a wide variety of “currently active” rules. On line 543, it says:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

For those who don’t read regular expressions, this rule will match any Date: header that contains a string like 201x, 202x, 203x, etc., where “x” could be replaced by any digit. So, back in 2008, this rule would catch email that claimed to hail from the year 2010 or later. (Well, up to 2099.)

Starting on the morning of last Friday, this rule started triggering on pretty much all mail that hadn’t been delayed, thus adding 3.384 points to every piece of incoming email. Naturally, this could easily push mail over the threshold from “not spam” into “spam” when it doesn’t belong there.

If you’ve been expecting some mail that hasn’t arrived, and your mail host uses SpamAssassin, you might want to check your spam folder.

According to a note on the SpamAssassin project’s main page, you can easily correct this problem in either of two ways:

  1. If your system is configured to use sa-update, run it now.
  2. Remove the FH_DATE_PAST_20XX rule altogether by putting “score FH_DATE_PAST_20XX 0″ at the end of your local.cf file.

Alternatively, if you’re the mail administrator, and you don’t mind setting up a Year 2020 Bug for yourself, you could always change the part that says Date =~ /20[1-9][0-9]/ so that it says Date =~ /20[2-9][0-9]/ instead. After all, stuff that claims to be from years in the future (or past) is likely to be something you don’t feel like reading. But if you do this, I strongly urge you to find some way to send yourself an alert around December of 2019, warning yourself that you need to fix that problem. (And that may be easier said than done.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

The more I play with OpenOffice.org’s Writer, the more confused I am by some of the odd UI/UX warts in it. Here are the ones that are on my mind this morning:

  • When I press F11 to bring up the Style Picker list, why does typing letters not navigate me through that list? Why do I have to use the down-arrow to navigate to “Heading 1″, rather than just typing “he” and then Enter?
  • Once I do hit Enter to apply the style I’ve chosen, why does the picker window remain open even though my cursor focus has returned to the document? This is the worst of both worlds: part of the document I’m working with is obscured by the picker window, and now I have to hit F11 twice in order to apply another style. If the window went away, I could just hit F11 once to bring it up the next time I wanted to apply a style.

    Read the rest of this entry »

    Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

A good long while ago, I tried doing an exercise that I was considering making into a standard job interview question: “For each of your ‘languages of choice’, tell me 5 things you like about the language, and 5 things you dislike about it.” My languages of choice at the time were Perl, PHP, and JavaScript, and my answers quickly showed me why this was not the best interview question:

It was far too easy to come up with dislikes, and not so easy to come up with likes. It was a perfect example of the adage that “Every programming language sucks, but some of them suck more.”

That said, the one language that scored more likes than dislikes, for me, was Perl. Here are some of the things I like about Perl:

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)
When you try to upgrade or install various PEAR (or PECL) packages, you may get the rather unhelpful error message "ERROR: `phpize' failed". For example, here's the result I get when I try to install the pecl_http package:

root@finrod:~# pecl install pecl_http
pecl/pecl_http can optionally use PHP extension "iconv"
downloading pecl_http-1.6.3.tar ...
Starting to download pecl_http-1.6.3.tar (Unknown size)
................................................................................
................................................................................
.........................................done: 1,015,808 bytes
71 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
ERROR: `phpize' failed
root@finrod:~#


The error is actually caused by a bug in PHP itself (filed in PHP's bug database as of 2004, and currently marked "Won't fix"): If your installation of PHP was compiled with the --enable-sigchild flag on, then the return value from a pclose() call can't be trusted. One of PEAR's components, called PEAR::Builder, uses pclose() as part of the package installation process, to try to determine whether a given operation succeeded or not.

Even though the operation succeeds, pclose() returns -1, signaling a failure, and the rest of PEAR then takes pclose() at its word.

Is This Affecting Your Installation of PHP and PEAR?

If you've gotten an "ERROR: `phpize' failed" message when trying to run a "pecl install" or "pear install" command, try running phpinfo() — if you see --enable-sigchild in the "Configure Command" section near the very top, then you're most likely being bitten by this bug.

Potential Fixes and Workarounds

The PHP dev team recommends recompiling without the offending flag.

However, you may not be able to do that, for any of various reasons. (You may have installed from a binary package, for instance — like most people these days.) Or it may simply seem like an excessive hassle. I offer the following patches as-is, without any guarantee or support.

To figure out which one to use, look in your PEAR/Builder.php file. On most Linux and Unix installations, this is likely to be in /usr/lib/php/PEAR/Builder.php, or possibly /usr/local/lib/php/PEAR/Builder.php.

On Windows systems, PHP might be installed nearly anywhere, but supposing it's in c:\php, then the file you're looking for will be in c:\php\PEAR\PEAR\Builder.php (yes, that's two PEARs in a row).

Check the "@version" line in the big comment block at the beginning of the file; the line you want should be around line 19 or so. If says it's less than version 1.38 (the latest one, at the time I'm writing this post), then try upgrading. Running "pear upgrade pear" should work. Then you can install this patch file:

patch-pear-builder-1.38.txt

Download the patch file and place it somewhere on your machine. Log in and cd to the PEAR directory that contains the Builder.php file. Then run the patch command. In the following example, I've placed the patch file in root's home directory:

root@finrod:~# ls
loadlin16c.txt loadlin16c.zip patch-pear-builder-1.38.txt
root@finrod:~# cd /usr/lib/php/PEAR
root@finrod:/usr/lib/php/PEAR# cp Builder.php Builder.bak.php
root@finrod:/usr/lib/php/PEAR# patch -p0 < /root/patch-pear-builder-1.38.txt
patching file Builder.php
root@finrod:/usr/lib/php/PEAR#


Naturally, if the patch file doesn't work for some reason, or it breaks things, you can just cp the backup file back into place.

Please let me know if this patch works for you — or if it fails horribly, for that matter.
kai_mactane: (Default)

When you try to upgrade or install various PEAR (or PECL) packages, you may get the rather unhelpful error message “ERROR: `phpize’ failed”. For example, here’s the result I get when I try to install the pecl_http package:

root@finrod:~# pecl install pecl_http
pecl/pecl_http can optionally use PHP extension "iconv"
downloading pecl_http-1.6.3.tar ...
Starting to download pecl_http-1.6.3.tar (Unknown size)
................................................................................
................................................................................
.........................................done: 1,015,808 bytes
71 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
ERROR: `phpize' failed
root@finrod:~#

The error is actually caused by a bug in PHP itself (filed in PHP’s bug database as of 2004, and currently marked “Won’t fix”): If your installation of PHP was compiled with the --enable-sigchild flag on, then the return value from a pclose() call can’t be trusted. One of PEAR’s components, called PEAR::Builder, uses pclose() as part of the package installation process, to try to determine whether a given operation succeeded or not.

Even though the operation succeeds, pclose() returns -1, signaling a failure, and the rest of PEAR then takes pclose() at its word.

Is This Affecting Your Installation of PHP and PEAR?

If you’ve gotten an “ERROR: `phpize’ failed” message when trying to run a “pecl install” or “pear install” command, try running phpinfo() — if you see --enable-sigchild in the “Configure Command” section near the very top, then you’re most likely being bitten by this bug.

Potential Fixes and Workarounds

The PHP dev team recommends recompiling without the offending flag.

However, you may not be able to do that, for any of various reasons. (You may have installed from a binary package, for instance — like most people these days.) Or it may simply seem like an excessive hassle. I offer the following patch as-is, without any guarantee or support.

First, ensure that you have the latest version of PEAR::Builder. Look in your PEAR/Builder.php file — On most Linux and Unix installations, this is likely to be in /usr/lib/php/PEAR/Builder.php, or possibly /usr/local/lib/php/PEAR/Builder.php.

On Windows systems, PHP might be installed nearly anywhere, but supposing it’s in c:\php, then the file you’re looking for will be in c:\php\PEAR\PEAR\Builder.php (yes, that’s two PEARs in a row).

Check the “@version” line in the big comment block at the beginning of the file; the line you want should be around line 19 or so. If says it’s less than version 1.38 (the latest one, at the time I’m writing this post), then try upgrading. Running “pear upgrade pear” should work. Then you can install this patch file:

patch-pear-builder-1.38.txt

Download the patch file and place it somewhere on your machine. Log in and cd to the PEAR directory that contains the Builder.php file. Then run the patch command. In the following example, I’ve placed the patch file in root’s home directory:

root@finrod:~# ls
loadlin16c.txt loadlin16c.zip patch-pear-builder-1.38.txt
root@finrod:~# cd /usr/lib/php/PEAR
root@finrod:/usr/lib/php/PEAR# cp Builder.php Builder.bak.php
root@finrod:/usr/lib/php/PEAR# patch -p0 < /root/patch-pear-builder-1.38.txt
patching file Builder.php
root@finrod:/usr/lib/php/PEAR#

Naturally, if the patch file doesn’t work for some reason, or it breaks things, you can just cp the backup file back into place.

Please let me know if this patch works for you — or if it fails horribly, for that matter.

[Updated 2009-06-03: Minor edits for clarity]

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 20th, 2017 09:55 pm
Powered by Dreamwidth Studios