Laughing Meme

Trying to use:

pear install Some_Package 

but getting

No release with state equal to: 'stable' found for Some_Package?

Some people will tell you to try:

pear install -f Some_Package 

(i.e. force install) A better solution is:

pear remote-info Some_Package

You’ll see near the top the latest version, e.g. Lastest: 0.8RC3.

Then you can do:

pear install Some_Package-0.8RC3

Sometimes you’ll already have a package installed (e.g. "Package 'Foo_Package' is already installed"), but need to upgrade to a unstable version.

pear remote-info Foo_Package

Package details:
================
Latest      1.0.2
Installed   1.0.1
...

pear install -f Foo_Package-1.0.2

This post is in the “things which should have been easy for someone to find with Google but aren’t” department, because sometimes you’d like to be able to tell someone DTFG, but you can’t. (previous examples included how to do conditional GETs in Perl). All material is lifted from excellent patch man pages, see “Notes for Patch Senders”.

Whats a patch?

A patch is the best and easiest way to submit changes back to an open source project. It’s a summary of changes you made to file or files formatted in a way that can easily be used by the excellent program, named, unsurprisingly, ‘patch’. Now because patch was written by the inestimable Larry Wall, patches can come in a wide range of shapes, sizes, and formats, and they will apply with a high degree of “do what I mean”-ness. However, there are some tips to produce high quality patches.

How to: the Short Answer

diff -Naur old new > patch_file

e.g.

diff -Naur rss_parse.inc rss_fetch_gopher.inc > add_gopher_support.patch

Slightly Longer Answer

The diff command’s headers should have dates and times in Universal Time using traditional Unix format, so that patch recipients can use the -Z or –set-utc option. Here is an example command, using Bourne shell syntax:

TZ=UTC0 diff -Naur gcc-2.7 gcc-2.8

Tips for Generating Usable Patch Files

1. Tell your recipients how to apply the patch by telling them which directory to cd to, and which patch options to use.
2. State clearly what the patch is suppose to accomplish, and which version it is meant to be applied to.
3. Your patch will be easier to apply if you place the original and patched sources next to each other in the file hierarchy so that the path depths to the files will be the same.
4. You can produce patches for entire directories of files, not just a single file, however try to keep your patches relatively straightforward, and thematically linked. This makes it easier to understand when something goes wrong.
5. I’m sure there are others. Did I miss your favorite?

Code improvements, and bug fixes are great, are wonderful, but patches make it much much easier to use them.

Jarno who says we shouldn’t use the timestamp in RSS feeds to sort the entries, also invites us to disagree. And I disagree. People keep forgetting that RSS pre-dates blogging, and is used for other tasks this pushing headlines to a desktop aggregator. Wish people would stop trying to limit us all because they lose sight of the bigger picture (as was done with Atom in my opinion) or are working with a poorly thought out spec. (Userland RSS) Just for the record, I’ve included below the algorithm I used to sort items into a collated list in one of my aggregators.

• check for a dc:date or pubDate per item, and assign the item that as its pub/mod date. (unfortunately for me, the handful of feeds published in Userland RSS I was aggregating were confused by the lastBuildDate tag, using it to keep track of the last build date for an item or a channel, instead of the item’s modification date, making it largely useless)
• otherwise, attempt to a certain the most recent publish time of the feed, by either looking at the channel’s dc:date, or the channel’s pubDate, and use that as the pub/mod time for all newly seen items.
• This has some nice features. Like, depending on how smart your aggregator is, it could do the right thing with the upcoming RSS feeds, even though they don’t use mod_event. (note to self, send Andy a note about that)

idly.org: With a lot of help from Magpie RSS, I have whipped up a personal listing page of events from Upcoming.org.

Cool!

After all parsing event bearing RSS is what Magpie was original written for (even if they aren’t using Magpie’s W3CDTF parsing)

For the person who seems to be frantically searching (lots of search referers) for how to use MagpieRSS with mod_content and content:encoded, here is how:

$rss = fetch_rss( $url );
foreach ( $rss->items as $item ) {
   echo "<p>title: $item['title']<br />";
   if ( isset($item['content']['encoded']) ) {
      echo $item['content']['encoded'];
   }
   echo "</p>";
}

I was arguing recently that implementing a conditional GET with LWP is trivial and there was no reason why someone wouldn’t support it. I assumed there must be a dozen examples of how to do this. Afterall O’reilly has “open sourced” their original LWP book, there is an LWP cookbook, and reams of POD.

No Such Luck

Well a quick search didn’t turn up anything. A more concerted one might have but it was easier to write this example then keep searching. If you’re looking for more general info on Conditional GETs try Charles Miller’s HTTP Conditional Get for RSS Hackers. If you’re looking for an implementation in PHP, you might look in rss_fetch of my RSS parser/aggregator Magpie.

Conditional GET

The basic idea is, when you request a file you remember the ETag and Last-Modified HTTP headers, passing them along with your next request as If-None-Match and If-Last-Modified. If the file has changed then you’ll get the content as normal, if the file hasn’t changed you’ll get a ’304 Not Modified’ header.

This is something of a toy example, but I try to be as correct as possible with it. Noteable in its absence is doing anything with the file you’ve fetched. (for example parsing and storing an RSS feed) Also I use a simple file to store ETag and Last-Modified, you might want to use a different backend.
See the Code

Example Code

use LWP::UserAgent;
use HTTP::Request;

my $url = "http://localhost/rss/laughingmeme.rdf";
my $cache_file = 'cache';
my %headers;

if ( -e $cache_file ) {
    open (CACHE, "< $cache_file") or die "Couldn't open: $!";
    %headers = (
        If_None_Match => <CACHE>,
        If_Last_Modified => <CACHE>
    );
    close CACHE;
}

my $ua = new LWP::UserAgent();
$ua->agent("Conditionally Enabled v0.1");

my $req = HTTP::Request->new( GET => $url );
$req->header(%headers);

my $res = $ua->request($req);
if ($res->is_success) {
    print "new!\n";
    # save ETag & Last-Modified
    open (CACHE, "> $cache_file") or die "Couldn't open: $!";
    print CACHE $res->header('ETag'), "\n";
    print CACHE $res->header('Last-Modified'), "\n";
    close CACHE;
}
elsif ( $res->code() eq '304' ) {
    print "not modified, go to cache\n";
    # do logic for RSS not modified
}
else {
    print "fooey! somthing went wrong\n";
}

Just wrote up some MagpieRSS recipes to answer a few of the frequently asked Magpie questions. Check out the MagpieRSS Cookbook. Hopefully followed by even greater amounts of documentation.