Monday, September 19, 2011

New cpanspec coming soon

I haven't released a new version of cpanspec in quite a while, but I have been working on it off and on with the help of several other people.  The big feature that I added was dependency extraction from tests, but I wasn't happy with the results of it.  Luckily, other people made it better, plus knocked a bunch of stuff off my TODO list.

The current list of changes looks like this:


  • Extract dependencies from tests.
  • Add script detection (patch from Jeff Fearn).
  • Lots and lots of patches from Dennis Kaarsemaker and Gavin Carr:
    • Drop cpanget and add the functionality to cpanspec.
    • Check the search path for rpm, rpmbuild, etc.
    • Add CC0 licence.
    • Change %{optimize} to %{optflags}.
    • Make tarball directory version component optional.
    • Add an option to print the generated specfile to stdout
    • Allow building rpms for slightly older perl versions
    • Check all build requirements against CPAN
    • Stop losing dependency version information for Module::Build, ExtUtils::MakeMaker, etc.
    • Strip any version comparison operator from the 'perl' build requirement
    • Add entries from configure_requres in META.yml as build dependencies
    • Detect scripts better
    • Don't let Module::AutoInstall run interactively
    • Add a simple blacklisting mechanism

In my light testing, this version has been working beautifully, but I'd really like to hear some more positive feedback before I push this out into Fedora, so if you package Perl modules, give it a try and let me know what you think.

Sunday, August 28, 2011

Vim: From Essentials to Mastery at OLF 2011


Ohio LinuxFest 2011 is coming up next week, September 9-11. As part of OLF Institute, Bill Odom and I will be teaching a full-day class on Vim on Friday, September 9. If you're like I was a year or so ago, and you think you know Vim just because you've been using vi forever, you really need to come to our class. Some of the things you can do with Vim will just blow your mind. (And if you don't even know vi, the class will be life-changing. :-)

The main conference is on Saturday, September 10. At 2PM, we'll have a special Vim Geeks Columbus BoF session which, like the rest of the conference on Saturday, you can attend for free.

For more information about the Vim class, see

  https://ohiolinux.org/olfi#VIM

For more information about OLF 2011, see the web site:

  http://ohiolinux.org/

For more information about Vim Geeks, our local Vim users group, see

  http://www.vimgeeks.org/

The full class description follows:

VIM: From Essentials to Mastery

Instructors: Steven Pritchard and Bill Odom

Vim deserves its reputation as one of the most powerful tools in an admin or developer's toolbox -- but it's not exactly friendly and approachable. Even long-time users rarely employ more than a fraction of its capabilities, and new users are often left wondering why so many apparently-sane people won't shut up about how awesome it is. The stark UI, the steep learning curve, the host of idiosyncrasies... mastering Vim is a challenge, and that's putting it politely.

In this class, you'll learn why it's worth the effort.

We'll start by covering the essentials of Vim, like modes, motions, operators, and commands, with an emphasis on why Vim works the way it does in addition to how it works. With the fundamentals firmly established, we'll work our way through real-world examples of using Vim to perform astounding feats that poor souls using lesser editors can only imagine. We'll cover ways to integrate Vim with your environment, tailor it to your work, and generally bend it to your every whim. We'll discuss important settings, advanced techniques, useful customizations, handy scripts, must-have plugins, crafty tips, and sneaky tricks.

In short, we'll explore how to use Vim most effectively, so it lives up to the awesome reputation that you'll soon be telling all your disbelieving friends about.

Bios: Steven Pritchard has nearly two decades of Linux and Unix experience. A dedicated Open Source advocate, he founded the Southern Illinois Linux Users Group in 1994 and has been a volunteer developer with Red Hat's Fedora Project since it began in 2003. He is also an author of the award winning LPI Linux Certification in a Nutshell, 2nd Ed (O'Reilly & Associates). Steven currently offers his technical services through the Computer Room, a retail technical sales and service company outside of St. Louis, Missouri.

Bill Odom has over two decades of experience as a systems architect and software developer, working on everything from wiki software for Internet startups to global identity management solutions for Fortune 500 companies. He's also a long-time member of the Open Source community, an active member (and periodic leader) of several user groups in the St. Louis area, and served as president of the Perl Foundation from 2005 through 2007.

Steven and Bill are both long-time users and advocates of Vim, and are the founders of the St. Louis Vim Geeks. They've given several well-received presentations, tutorials, and classes on Vim to many Midwest organizations.

Thursday, October 21, 2010

Regular Expressions

Slides from my talk at last night's St. Louis Perl Mongers meeting:

Tuesday, September 28, 2010

String::Random

I mentioned my one module on CPAN (String::Random) to a friend yesterday, and got the response "You wrote that?"  Honestly, I was shocked that he'd heard of it.  (There are so many modules on CPAN that I doubt most Perl programmers have heard of 99% of them.)

I decided to Google for the module a bit to see if there were many mentions (fully expecting to find some "I looked at the code, and my eyes are still bleeding" comments), and I was pleasantly surprised to find this rather old tutorial on using the module: http://www.perlmonks.org/?node_id=88021

I also found a Ruby port on GitHub: http://github.com/repeatedly/ruby-string-random

So far, I haven't found anyone ripping into it, but I'm sure it's out there...

Thursday, August 19, 2010

Ohio Linux Fest

It's time again for the Ohio Linux Fest (September 10-12, 2010 in Columbus, Ohio).  I'm going.  So should you.  :-)

I'm teaching an abbreviated version of my Data Recovery class (for an abbreviated price, I might add) as part of the OLFU program on Friday, September 11.  If you are responsible for any hard drives, I highly recommend the class.

Speaking of classes, we also just announced a tag-team vi and vim class lineup that Bill Odom and I will be doing late next month.  Anyone in the St. Louis area who uses vi and thinks it is a burden (or avoids it like the plague) should take my vi basics class.  Everyone should take Bill's vim class.  (It's amazing stuff.)

Thursday, July 29, 2010

Generating ssh keys in PuTTY

I had to fire up Windows today to explain to someone how to generate ssh keys (for use with PuTTY).  I figured since I went to all that trouble, I should share...

Note: The Linux version of puttygen is all command-line, so these instructions will only work with the Windows version.


When you first run puttygen, the default (along the bottom) should be to create a key type "SSH-2 RSA". If not, select that. 1024 bits is fine (box at the very bottom right), which should be the default.


Now, hit "Generate". It will ask you to move the mouse around a bit to generate some randomness. When that is done, it will generate the key. Put your email address in the "Key comment" field. Then select the key in the box at the top (under "Public key for pasting into OpenSSH authorized_keys file:"), copy it, and paste it into the .ssh/authorized_keys on the system you want to be able to login to with that key.


Fill in the box next to "Key passphrase" with something long that you'll remember. (It's fine to use a full sentence or something. Remember, it's a passphrase, not a password.) Enter the passphrase again in the "Confirm passphrase" box.


Next hit the "Save public key" button and save that half to a file with "public" in the file name. Then hit the "Save private key" button and save that half to a file with "private" in the file name.


In PuTTY, in the configuration dialog, expand "Connection" in the left pane (if it isn't already), then expand "SSH". Click on "Auth". Next to the box that says "Private key file for authentication", hit "Browse" and select the "private" file you just saved. Be sure to save your settings so you don't have to feed this in every time. (Click on "Session" at the top of the left pane, then under "Saved Sessions" click on "Default Settings" and hit "Save".)


Now when you try to login to the system you previously dropped your public key on, you should be prompted for the passphrase for your key rather than the password for your account on the system.

If I may add a little editorializing here, I do have to point out that this is all much easier with ssh-keygen on Linux.  And, IMHO, if you're doing Linux administration from a Windows PC, you're doing it wrong.  But that's just me.  :-)

Friday, February 26, 2010

Stupid git tricks

I had a directory in CVS that I used for a catch-all for random scripts. (For example, this is where cpanspec lived before moving it to Sourceforge CVS.) Now that I'm using github, I'm trying to split these scripts up into separate git repos. This is the procedure I've come up with...

First I use git cvsimport to pull in the whole CVS tree:
git cvsimport -d :ext:user@host:/cvsroot -C myscript cvs_module
This will create a directory named myscript. Next, go into that directory and use git filter-branch to remove everything but the file(s) we care about (in this case, myscript again).
git filter-branch --prune-empty --tree-filter 'find -maxdepth 1 -type f \! -name myscript -delete' HEAD
This ends up leaving some stale objects that can be cleaned up by removing everything other than master in .git/refs/heads/, the entire directory .git/refs/original/, and any unrelated tags in .git/refs/tags/ (at least in my example with no branches and such), then cleaning up with a few git commands:
git gc --aggressive
git prune
git repack -a -d

The total number of objects listed by git gc and git repack should be much smaller than the original number git cvsimport reported. (I also confirmed that git fsck --unreachable doesn't find anything.)

[Update] Apparently I had found this answer to my problem a while back and forgot about it. Oops.