Tiger

How to fix "can't find package Pextlib 1.0" in MacPorts installation

Installing MacPorts (formerly DarwinPorts), I ran into an issue with the post-installation selfupdate command which took some digging to solve. Eventually, I tracked it down to this thread at gmane.org.

Two fixes need to be made: adding a missing line in a text file, and replacing a PPC binary with an Intel-compatible version.

First up, follow the installation instructions at the MacPorts wiki: InstallingMacPorts.

After installation is complete and the installer app is quit:

  1. Right-click on the .pkg launcher (which is as of this writing called "MacPorts-1.4.0.pkg") and select "Show Package Contents".
  2. Navigate into the "Contents" folder and double-click on the "Archive.pax.gz" file. This will result in an "Archive" folder in your Downloads folder.
  3. In the Terminal:
    cd /opt/local/share/darwinports/Tcl/pextlib1.0
  4. Open "pkgIndex.tcl" in your favorite Terminal text editor. Assuming vim:
    sudo vim pkgIndex.tcl
  5. On the first blank line (below the commented text), add this text all on the same line:
    package ifneeded Pextlib 1.0 [list load [file join Pextlib.dylib]]
  6. Save and quit the editor.
  7. Backup the incompatible binary just in case:
    mv Pextlib.dylib Pextlib.dylib.old
  8. Use the command open . to reveal this directory in a Finder window.
  9. Leaving this window open, open a second Finder window and go to the corresponding folder in the Archive you extracted in step 2. It will be at "Archive/opt/local/share/darwinports/Tcl/pextlib1.0"
  10. Copy the "Pextlib.dylib" file from the Archive into the permanent folder.

Back in the Terminal, your sudo port selfupdate command should work now. You can trash the Archive folder and Archive.paz file from your Downloads folder.

Note: see comments for another approach in step 5 that worked for at least one visitor.

And for your reference, here's the original error message I got when I first ran the selfupdate:

can't find package Pextlib 1.0  
    while executing  
"package_native require Pextlib 1.0"  
    ("eval" body line 1)  
    invoked from within  
"eval package_native $args"  
    (procedure "package" line 14)  
    invoked from within  
"package require Pextlib 1.0"  
    (procedure "dportinit" line 315)  
    invoked from within  
"dportinit ui_options global_options global_variations"  
Error: /opt/local/bin/port: Failed to initialize ports system, 
can't find package Pextlib 1.0

SEPT 2009 UPDATE: Apparently some folks are running into this same issue with new Snow Leopard installations. See the more recent comments below for more info.

kGTD not GTD well enough

kGTD is pissing me off. :)

Generally speaking, it has done a serviceable job during my recent experiments, even if it has (understandably) slowed down as dozens of projects and scores of actions are added.

But where it's beginning to fail is on the recurring actions. There's some sort of screwy thing going on during syncing where random recurring items are either “completed” out of repetition (and thus existence) or are kept moving to the next day.

This is not acceptable for a system that is supposed to be trusted; unfortunately, since kGTD is apparently not going to be updated with the still-unscheduled appearance of OmniFocus, I am forced to look at other options.

I think I have three or so choices (which isn't to say there aren't others), not counting sticking with kGTD for now. None of them is ideal; all of them will be supplemented (and thus improved) by using Quicksilver as the main entry method.

  1. Anticipating Leopard's coming improvements, trying an iCal-only system even though its current slowness is a big drawback.
  2. Cobbling together something with Remind, as I'm well-familiar with its syntax and could get back up to speed pretty quickly.
  3. Switching over to the quickly evolving iGTD.
  4. Some combination thereof, e.g. using Rem2ics and iCal to Remind.

More later. It's time to get my muffins prepped for baking. :)

links for 2007-03-30

Mmmmm... mutt

I have had occasion in the past to fall in love with the CLI email client "mutt" -- last year, in fact, it wound up being a great resource while I made various server consolidation and administration moves and was spending a lot of time in term windows.

There are several guides out there for setting up mutt, but it's always nice to find a newly updated one with the latest info. Via an article on macosxhints comes this great linsec.ca guide: "Using mutt on OS X" by vdanen. He covers everything from installation, building/compiling, and the usual setup stuff, then moves on to what have been deal-killers for folks in the past -- Address Book integration, attachment handling, improved threading, and other coolness. Definitely recommended.

Myself, I'm holding out to see how Leopard's improvements work out. "Stationery" and a "media browser" don't bode well. ;) Notes and to-dos are intriguing, however.

Minimizing Mail

unobtrusive mail program

Do you recognize the program window above? You can probably guess based on the title of the page you're reading, but yes, that is Mac OS X Mail. You'll immediately notice a couple of things.

First, there is no email. This is due to aggressive and as immediate as possible processing on my part -- emails need to either be archived, generate replies and then archived, or generate todo items then archived. Or deleted if no archive is required.

Next, the sidebar is missing. (In previous versions, it would be a drawer instead.) If I do need to access the sidebar folders, Command-Shift-M will show and hide it again. I use a single Archive folder. (See Filing Away for how this is possible.) With that in mind, using the keyboard shortcut Command-Option-T will move selected email to the Archive magically, once you've done it once. Navigating between the major boxes (if necessary) is done with the Command-1 through Command-6 shortcuts. By the way, I do have four different inboxes for four different POP and IMAP accounts, but it is set up to display them all at once.

Lastly, the top menubar icons is missing -- this comes from having learned the big shortcuts -- Command-R to Reply, Command-Shift-F to Forward, Command-Shift-R to Reply-All, etc. Hitting Return with a message highlighted in the Inbox will open a message window, in which all of these commands, as well as the Delete button and Archive shortcut above work, too. So I rarely have to move my hands to the mouse.

When you have a message window up, hide the toolbar and size the window down as small as you like. The size and preference of different kind of emails are kept track separately (Read Message window, Reply window, Forward window, New Message window), so you'll just need to do it once for each.

One other mouse hold-up is if you are composing a new message (or reply or forward) and wish to switch what account you are using to send it. What I've done is to go to the Keyboard & Mouse System Preference, to the Keyboard Shortcuts tab, and turn Full Keyboard Access to "All Controls." This allows me to tab to the popup menus I need.

What does this achieve? Well, it's less obtrusive, and for my purposes this footprint helps me with the mental buffer around my "real" work that I'm trying to keep. Mail will always be a distraction, but if I make these changes, combined with turning off crazy notifications, popups, and blinkenlights, the flow of work is much less interrupted. In a GTD context, I am also able to put things in their proper bins much more easily. It is also all about Reducing Friction.

Not all email clients will have the ability to minimize this much, but the principles are the same -- hide things away as much as possible. You'll instinctively know when it's time to see if you have new email -- and I bet it isn't every last minute of the day.

Dashboard

hula girl on a dashboard

Finally, a truly useful Widget: The Hitch Hiker's Guide to the Galaxy -- play the 1984 Infocom text-based adventure game. "Memories..." </renandstimpy>

The mighty return of Desk Accessories! :)

One of the major things that Konfabulator users crow about -- i.e., not having to reveal the Widgets with a special key -- is for me one of Dashboard's best features. Besides, if you do want to detach a Widget, there's a macosxhints.com article that will tell you how to do it. There's also Amnesty, which puts up a Menu Bar item for running Widgets independent of Dashboard.

Check out the dashboard tag on Flickr for some cool screenshots.

My must-have Widgets (not built-in)

Although I don't use Dashboard much nowadays, here are some essentials:

Apple has a Dashboard Widgets repository online naturally, but it doesn't always have the latest greatest. Try MacUpdate for more.

Syndicate content