From jameschoate at austin.rr.com Fri Apr 2 14:56:52 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Fri, 2 Apr 2010 21:56:52 +0000 Subject: APM: Confusion Research Center Update Message-ID: <20100402215652.1V4I1.584937.root@hrndva-web18-z02> Among other activities we are going to begin having a twice monthly social on Fridays from 7-9pm. The first events will be Apr. 9 and Apr. 23. These will be an interim event until we get a physical location opened early summer. For more information and up to date news please visit, http://hackerspaces.org/wiki/Confusion_Research_Center -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- -- From jameschoate at austin.rr.com Tue Apr 6 09:00:09 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Tue, 6 Apr 2010 16:00:09 +0000 Subject: APM: On Generation of Firewall Log Status Reporter (SRr) Using Perl Message-ID: <20100406160009.Q22YB.604390.root@hrndva-web26-z02> http://arxiv.org/abs/1004.0604 Computer System Administration and Network Administration are few such areas where Practical Extraction Reporting Language (Perl) has robust utilization these days apart from Bioinformatics. The key role of a System/Network Administrator is to monitor log files. Log file are updated every day. To scan the summary of large log files and to quickly determine if there is anything wrong with the server or network we develop a Firewall Log Status Reporter (SRr). SRr helps to generate the reports based on the parameters of interest. SRr provides the facility to admin to generate the individual firewall report or all reports in one go. By scrutinizing the results of the reports admin can trace how many times a particular request has been made from which source to which destination and can track the errors easily. Perl scripts can be seen as the UNIX script replacement in future arena and SRr is one development with the same hope that we can believe in. SRr is a generalized and customizable utility completely written in Perl and may be used for text mining and data mining application in Bioinformatics research and development too. -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- -- From tmcd at panix.com Wed Apr 7 11:37:09 2010 From: tmcd at panix.com (Tim McDaniel) Date: Wed, 7 Apr 2010 13:37:09 -0500 (CDT) Subject: APM: CPANP / CPANPLUS / CPAN++? Message-ID: For the first time in a while, I went into cpan and did an upgrade. It installed or upgraded CPANPLUS. I'm finding it hard to Goole more than the most basic info that it's a Perl package manager (or deep details that I don't care about yet). Should I be using CPANPLUS instead of CPAN? How would I use it to update the installed Perl modules? -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Wed Apr 7 19:39:09 2010 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Wed, 7 Apr 2010 21:39:09 -0500 Subject: APM: CPANP / CPANPLUS / CPAN++? In-Reply-To: References: Message-ID: CPANPLUS is a library offering an enhanced API by which to interact with CPAN mirrors. You can access these new features programmatically via CPANPLUS::Backend, or, if you're just looking for regular old CPAN-shell functionality, you have a choice of any of the options in the CPANPLUS::Shell::* namespace. You'll get the default shell by simply issuing the command - 'cpanp'. Once at the cpanp prompt ('cpanp>') type 'h', just like the classic cpan shell, for a help menu... So why bother? Well, it's really a matter of preference and whether you think you need the additional functionality. Do you ever find yourself wanting to uninstall a module and reinstall a previous version in a simple and automated way? Did you ever find yourself wanting to use a simple shell to install a module's tar.gz bundle from local disk (or from a custom, non CPAN mirror, URL) without all the manual invocation, dependency checking, and having to be aware of the module's build system intricacies such as whether it used ExtUtils::Makemaker or Module::Build? Then maybe CPANPLUS is for you... As always, there's an awful lot of documentation available through your local CPAN mirror. Try 'perldoc CPANPLUS::Shell::Default' for a quick start on the default shell... Hope that helps, m On Wed, Apr 7, 2010 at 1:37 PM, Tim McDaniel wrote: > For the first time in a while, I went into cpan and did an upgrade. > It installed or upgraded CPANPLUS. I'm finding it hard to Goole more > than the most basic info that it's a Perl package manager (or deep > details that I don't care about yet). > > Should I be using CPANPLUS instead of CPAN? How would I use it to > update the installed Perl modules? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcd at panix.com Thu Apr 8 14:15:35 2010 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 8 Apr 2010 16:15:35 -0500 (CDT) Subject: APM: 5.12? Message-ID: How can I find out what is in the release candidates for Perl 5.12? -- Tim McDaniel, tmcd at panix.com From tshinnic at io.com Thu Apr 8 14:27:58 2010 From: tshinnic at io.com (Thomas L. Shinnick) Date: Thu, 08 Apr 2010 16:27:58 -0500 Subject: APM: 5.12? In-Reply-To: References: Message-ID: <8crgll$gudhd@asav00.insightbb.com> At 04:15 PM 4/8/2010, Tim McDaniel wrote: >How can I find out what is in the release candidates for Perl 5.12? http://search.cpan.org/~jesse/perl-5.12.0-RC4/pod/perl5120delta.pod I thought to see if the file date was recent, but all the pods have yesterday's date. It does have a different (larger) size than RC3, so someone is updating it? Still this is a start... >-- >Tim McDaniel, tmcd at panix.com >_______________________________________________ >Austin mailing list >Austin at pm.org >http://mail.pm.org/mailman/listinfo/austin From tmcd at panix.com Thu Apr 8 14:58:40 2010 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 8 Apr 2010 16:58:40 -0500 (CDT) Subject: APM: 5.12? In-Reply-To: <8crgll$gudhd@asav00.insightbb.com> References: <8crgll$gudhd@asav00.insightbb.com> Message-ID: On Thu, 8 Apr 2010, Thomas L. Shinnick wrote: > At 04:15 PM 4/8/2010, Tim McDaniel wrote: >> How can I find out what is in the release candidates for Perl 5.12? > > http://search.cpan.org/~jesse/perl-5.12.0-RC4/pod/perl5120delta.pod Thanks! -- Tim McDaniel, tmcd at panix.com From tmcd at panix.com Fri Apr 9 09:58:18 2010 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 9 Apr 2010 11:58:18 -0500 (CDT) Subject: APM: The proper way to use CPAN on a server Message-ID: I've been lazy due to being on a single-user machine, either at home or a Windows box at work. I got IT at work to install Perl 5.10.1 on a server. I want to update the modules for all users. I've had an odd amount of trouble finding info on the Proper Way to upgrade -- maybe my Google-fu is weak today. Is it as simple as "sudo cpan upgrade"? Should I worry about upgrading CPAN itself first, if necessary, and if so, how? Are there any modifications due to Red Hat Enterprise Linux Server release 5.4 (Tikanga) ? -- Tim McDaniel, tmcd at panix.com From duff at pobox.com Fri Apr 9 10:32:40 2010 From: duff at pobox.com (Jonathan Scott Duff) Date: Fri, 9 Apr 2010 12:32:40 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: I typically don't run cpan via sudo but rather set the install commands within cpan to use sudo. From the cpan> prompt: cpan> o conf make_install_make_command 'sudo /usr/bin/make' cpan> o conf mbuild_install_build_command 'sudo ./Build' cpan> o conf commit # may not be needed Then, whenever you install via cpan, it will use sudo to install modules. Also, I often will run cpan thusly: $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN That causes cpan to accept the default answers to any prompts as it installs the CPAN bundle. This is usually so I don't have to repeatedly answer "y" to install required modules. Since you're asking about upgrading, there's another useful thing you can do: perl -MCPAN -e 'CPAN->upgrade(/^Catalyst::/)' That'll upgrade all of the installed modules that start with "Catalyst::" read the CPAN docs for more info. hope this helps, -Scott On Fri, Apr 9, 2010 at 11:58 AM, Tim McDaniel wrote: > I've been lazy due to being on a single-user machine, either at home > or a Windows box at work. > > I got IT at work to install Perl 5.10.1 on a server. I want to update > the modules for all users. I've had an odd amount of trouble finding > info on the Proper Way to upgrade -- maybe my Google-fu is weak today. > Is it as simple as "sudo cpan upgrade"? Should I worry about > upgrading CPAN itself first, if necessary, and if so, how? Are there > any modifications due to > Red Hat Enterprise Linux Server release 5.4 (Tikanga) > ? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmaynard at outserv.net Fri Apr 9 10:53:39 2010 From: dmaynard at outserv.net (David Maynard) Date: Fri, 9 Apr 2010 12:53:39 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: This usually isn?t very popular with developers, but if it is a production server we don?t use CPAN if we can avoid it. Instead we install RPM packages of the modules. The main reason is that we want to have repeatable server builds. It also helps you need the code to be portable to ?stock? Red Hat systems. For Red Hat/CentOS, the DAG (http://dag.wieers.com/) yum/RPM repository has a good selection of Perl packages. There are a couple of other repositories that tend to have more bleeding-edge versions, but they haven?t been around as long. -dpm From: austin-bounces+dmaynard=outserv.net at pm.org [mailto:austin-bounces+dmaynard=outserv.net at pm.org] On Behalf Of Jonathan Scott Duff Sent: Friday, April 09, 2010 12:33 PM To: Tim McDaniel Cc: Austin at pm.org Subject: Re: APM: The proper way to use CPAN on a server I typically don't run cpan via sudo but rather set the install commands within cpan to use sudo. From the cpan> prompt: cpan> o conf make_install_make_command 'sudo /usr/bin/make' cpan> o conf mbuild_install_build_command 'sudo ./Build' cpan> o conf commit # may not be needed Then, whenever you install via cpan, it will use sudo to install modules. Also, I often will run cpan thusly: $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN That causes cpan to accept the default answers to any prompts as it installs the CPAN bundle. This is usually so I don't have to repeatedly answer "y" to install required modules. Since you're asking about upgrading, there's another useful thing you can do: perl -MCPAN -e 'CPAN->upgrade(/^Catalyst::/)' That'll upgrade all of the installed modules that start with "Catalyst::" read the CPAN docs for more info. hope this helps, -Scott On Fri, Apr 9, 2010 at 11:58 AM, Tim McDaniel wrote: I've been lazy due to being on a single-user machine, either at home or a Windows box at work. I got IT at work to install Perl 5.10.1 on a server. I want to update the modules for all users. I've had an odd amount of trouble finding info on the Proper Way to upgrade -- maybe my Google-fu is weak today. Is it as simple as "sudo cpan upgrade"? Should I worry about upgrading CPAN itself first, if necessary, and if so, how? Are there any modifications due to Red Hat Enterprise Linux Server release 5.4 (Tikanga) ? -- Tim McDaniel, tmcd at panix.com _______________________________________________ Austin mailing list Austin at pm.org http://mail.pm.org/mailman/listinfo/austin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at laceytech.com Fri Apr 9 10:55:57 2010 From: jim at laceytech.com (Jim Lacey) Date: Fri, 9 Apr 2010 12:55:57 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: Great tip about the upgrade. I have been using the $ PERL_MM_USE_DEFAULT=1 for some time. Invaluable especially loading Catalyst Jim On Fri, Apr 9, 2010 at 12:32 PM, Jonathan Scott Duff wrote: > > > > > Since you're asking about upgrading, there's another useful thing you can > do: > > perl -MCPAN -e 'CPAN->upgrade(/^Catalyst::/)' > > > > -- James Lacey Laceytech LLC 11607 Buckingham Road Austin, TX 78759 +1 512 335 7422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcd at panix.com Fri Apr 9 10:57:05 2010 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 9 Apr 2010 12:57:05 -0500 (CDT) Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: On Fri, 9 Apr 2010, Jonathan Scott Duff wrote: > Also, I often will run cpan thusly: > > $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN > > That causes cpan to accept the default answers to any prompts as it > installs the CPAN bundle. Just to make sure: that should be PERL_MM_USE_DEFAULT=1 cpan install Bundle::CPAN ? -- Tim McDaniel, tmcd at panix.com From duff at pobox.com Fri Apr 9 11:01:17 2010 From: duff at pobox.com (Jonathan Scott Duff) Date: Fri, 9 Apr 2010 13:01:17 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: On Fri, Apr 9, 2010 at 12:57 PM, Tim McDaniel wrote: > On Fri, 9 Apr 2010, Jonathan Scott Duff wrote: > >> Also, I often will run cpan thusly: >> >> $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN >> >> That causes cpan to accept the default answers to any prompts as it >> installs the CPAN bundle. >> > > Just to make sure: that should be > > PERL_MM_USE_DEFAULT=1 cpan install Bundle::CPAN Nope. That's meant to be run from the command line using the "cpan" command which doesn't take subcommands. So cpan Bundle::CPAN from the command line will install Bundle::CPAN. -Scott > ? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duff at pobox.com Fri Apr 9 11:05:29 2010 From: duff at pobox.com (Jonathan Scott Duff) Date: Fri, 9 Apr 2010 13:05:29 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: On Fri, Apr 9, 2010 at 12:53 PM, David Maynard wrote: > This usually isn?t very popular with developers, but if it is a > production server we don?t use CPAN if we can avoid it. Instead we install > RPM packages of the modules. The main reason is that we want to have > repeatable server builds. It also helps you need the code to be portable to > ?stock? Red Hat systems. > Indeed. Relying on your package manager is the recommended way for servers ... when you can get packages that have all of the things you need. :-) For the longest time we would use CPAN to install PDL because the RedHat package was broken in some way that was important to us (it's been a while, so I forget the specifics). But now we just the perl-PDL package and don't worry about getting it from CPAN. -Scott > For Red Hat/CentOS, the DAG (http://dag.wieers.com/) yum/RPM repository > has a good selection of Perl packages. There are a couple of other > repositories that tend to have more bleeding-edge versions, but they haven?t > been around as long. > > > > -dpm > > > > *From:* austin-bounces+dmaynard=outserv.net at pm.org [mailto: > austin-bounces+dmaynard =outserv.net at pm.org] *On > Behalf Of *Jonathan Scott Duff > *Sent:* Friday, April 09, 2010 12:33 PM > *To:* Tim McDaniel > *Cc:* Austin at pm.org > *Subject:* Re: APM: The proper way to use CPAN on a server > > > > I typically don't run cpan via sudo but rather set the install commands > within cpan to use sudo. From the cpan> prompt: > > > > cpan> o conf make_install_make_command 'sudo /usr/bin/make' > > cpan> o conf mbuild_install_build_command 'sudo ./Build' > > cpan> o conf commit # may not be needed > > > > Then, whenever you install via cpan, it will use sudo to install modules. > > > > Also, I often will run cpan thusly: > > > > $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN > > > > That causes cpan to accept the default answers to any prompts as it > installs the CPAN bundle. This is usually so I don't have to repeatedly > answer "y" to install required modules. > > > > Since you're asking about upgrading, there's another useful thing you can > do: > > > > perl -MCPAN -e 'CPAN->upgrade(/^Catalyst::/)' > > > > That'll upgrade all of the installed modules that start with "Catalyst::" > read the CPAN docs for more info. > > > > hope this helps, > > > > -Scott > > > > On Fri, Apr 9, 2010 at 11:58 AM, Tim McDaniel wrote: > > I've been lazy due to being on a single-user machine, either at home > or a Windows box at work. > > I got IT at work to install Perl 5.10.1 on a server. I want to update > the modules for all users. I've had an odd amount of trouble finding > info on the Proper Way to upgrade -- maybe my Google-fu is weak today. > Is it as simple as "sudo cpan upgrade"? Should I worry about > upgrading CPAN itself first, if necessary, and if so, how? Are there > any modifications due to > Red Hat Enterprise Linux Server release 5.4 (Tikanga) > ? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcd at panix.com Fri Apr 9 11:09:04 2010 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 9 Apr 2010 13:09:04 -0500 (CDT) Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: On Fri, 9 Apr 2010, David Maynard wrote: > This usually isn't very popular with developers, but if it > is a production server we don't use CPAN if we can avoid it. > Instead we install RPM packages of the modules. The main reason is > that we want to have repeatable server builds. It also helps you > need the code to be portable to "stock" Hat systems. > > For Red Hat/CentOS, the DAG (http://dag.wieers.com/) yum/RPM > repository has a good selection of Perl packages. There are a > couple of other repositories that tend to have more bleeding-edge > versions, but they haven't been around as long. Can you expand on that, please? I'm not familiar with Red Hat systems, yum, RPM, and all that. Given your requirement for "repeatable server builds", I'm guessing that you somehow download specific *.rpm files into a repository that's networked within your site, and then on any particular server, mount or copy from the repository and run command(s) to install using those files. In my case, luckily this is a proof-of-concept installation of tools that are unrelated to the server's purpose, so I have a lot of freedom. -- Tim McDaniel, tmcd at panix.com From tmcd at panix.com Fri Apr 9 11:11:41 2010 From: tmcd at panix.com (Tim McDaniel) Date: Fri, 9 Apr 2010 13:11:41 -0500 (CDT) Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: On Fri, 9 Apr 2010, Jonathan Scott Duff wrote: > $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN ... > That's meant to be run from the command line using the "cpan" > command which doesn't take subcommands. So cpan Bundle::CPAN from > the command line will install Bundle::CPAN. Thank you for the explanation. -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Fri Apr 9 13:27:49 2010 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 9 Apr 2010 15:27:49 -0500 Subject: APM: The proper way to use CPAN on a server In-Reply-To: References: Message-ID: This may be slightly off-topic (as I'm not really addressing the question about cpan-shell syntax problems), and I may be running the risk of starting a flame war, sorry, but, speaking as a Developer (and former SysAdmin): waiting on RedHat to distribute RPMs (a practice which is advised and necessary for the system-Perl) is a *horrible* way to manage Perl modules that are depended on by non-trivial applications. I'm stuck in a RedHat environment and would never rely on them to get it right for any of the critical systems I work on at my job if it could possibly be avoided... RedHat's track record with Perl module maintenance is not great (and this criticism isn't limited to RedHat: Apple had broken system Perl libraries for many many months in 2008 also, and I'm positively sure there are vendors with this problem). If Perl is important to you and your job, build it yourself from source! As a "best practice" for managing Perl and Perl modules here's what I do (your mileage may vary): 1. Compile and install a custom Perl (or multiple Perl versions) using a non-root account, perhaps under /usr/local or /opt. You can use symlinks to simplify the paths for these; and symlinks have the added advantage of flexibility... i.e. upgrades are simple. E.g. /opt/perl -> /opt/perl-5.10.1/ , makes an eventual update to 5.12 trivial both to test and to implement with no changes required to consuming code simply by changing the appropriate symlinks. [Importantly, this way you can be sure that you aren't going to break the system Perl install by upgrading modules, which should put your SAs at ease. My advice: NEVER MESS WITH THE SYSTEM PERL, AND NEVER RELY ON IT FOR ALL BUT THE MOST TRIVIAL (simple one-off script) CASES! Sorry for shouting: I've learned the hard way that this is a recipe for pure frustration and pain...] 2. Update your path: e.g. PATH=/opt/perl/bin:$PATH if you use bash... you can just stick this in your .bashrc. 3. To address firewall restrictions in a corporate server environment that might make contacting a public CPAN mirror impossible, create your own mini-CPAN bundle to act as a local CPAN mirror on your secure network (or a local filesystem if that's not possible). This archive adds some maintenance overhead (you'll need to update it occasionally), but for any non-trivial installation base it is absolutely fantastic (and surprisingly easy to do)! See CPAN::Mini. 4. Configure your CPAN shell to point to the URL of your mini-CPAN (any of file://, http://, or ftp:// are appropriate depending on how it is accessible). I find it convenient to store the mini-CPAN archive on a webserver and create a symlink under htdocs so that this archive is available on the internal network via http without having to get a firewall exception everytime you need to install a module from a public mirror... but you'll probably need to have a talk with your security team before you get the go-ahead. There's an additional advantage here in that if you are creating standard Perl packaged modules in your organization, they can be 'injected' into your private mini-CPAN mirror for simple automated distribution via the CPAN shell to any end users who can access the URL of your mini-CPAN. Using sudo should not be required to install modules for Perls that have been installed by a non-privileged account: so, to install a module just issue the command 'cpan -i Some::Module' for any system who's CPAN shell is configured to point to this URL. 5. For 'repeatable server builds' I've found it much easier to use a shared file-system (prefer a snap-mirrored NAS for HA reliability, but NFS, or SAMBA are possible too). Build the Perls there and create symlinks on each host according to any platform specific details: e.g. /opt/perl -> [ /opt/NAS/perl-5.10.1, /opt/NAS/perl-5.10.1_x64 ]. So, now, (although you have to compile and install the same module for each individual Perl build) you can manage all the modules in one central location for all systems that have this mount... which could potentially be a very large installation base. This way the 'repeatable' part of any server build is as simple as adding a line to fstab so that the new device is mounted at boot and an appropriate symlink is created for each new host. There's a small amount of overhead with this approach (not as much as you think though, esp. compared to the alternatives), but it *scales well* which is very important if you depend on a Perl infrastructure for applications (as opposed to simpler Perl use by the system-OS or Admins). For further reading along these lines there's some great information that Schwern put together here: http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices Hope that helps, m On Fri, Apr 9, 2010 at 1:11 PM, Tim McDaniel wrote: > On Fri, 9 Apr 2010, Jonathan Scott Duff wrote: > >> $ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN >> > ... > >> That's meant to be run from the command line using the "cpan" >> >> command which doesn't take subcommands. So cpan Bundle::CPAN from >> the command line will install Bundle::CPAN. >> > > Thank you for the explanation. > > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcd at panix.com Tue Apr 13 13:23:02 2010 From: tmcd at panix.com (Tim McDaniel) Date: Tue, 13 Apr 2010 15:23:02 -0500 (CDT) Subject: APM: Configuring Perl Message-ID: I'm running ./Configure in preparation for building perl. /etc/redhat-release is Red Hat Enterprise Linux Server release 5.3 (Tikanga). I'm inclined to just accept the defaults for everything (except I did "./Configure -Dprefix=/opt/perl/perl-5.10.1" so that it has its own playpen). But I'm uncertain about threading support and multiplicity. The defaults are "n"; should I select either or both? If I want code to run under Apache, maybe using mod_perl, should the answers change? -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Tue Apr 13 15:33:48 2010 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Tue, 13 Apr 2010 17:33:48 -0500 Subject: APM: Configuring Perl In-Reply-To: References: Message-ID: You can check the configuration of the currently installed system-perl with 'perl -V'. This will issue more information than you ever wanted to know about a Perl install which you could then use as a template for the new build... But, off hand I'd say leave the defaults as-is unless you have something esoteric planned... in my experience the '-Dprefix=/path/to/install' is the most usefull option with Configure. Hope that helps, m On Tue, Apr 13, 2010 at 3:23 PM, Tim McDaniel wrote: > I'm running ./Configure in preparation for building perl. > /etc/redhat-release is Red Hat Enterprise Linux Server release 5.3 > (Tikanga). > > I'm inclined to just accept the defaults for everything (except I did > "./Configure -Dprefix=/opt/perl/perl-5.10.1" so that it has its own > playpen). But I'm uncertain about threading support and multiplicity. > The defaults are "n"; should I select either or both? If I want code > to run under Apache, maybe using mod_perl, should the answers change? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcd at panix.com Tue Apr 13 15:48:36 2010 From: tmcd at panix.com (Tim McDaniel) Date: Tue, 13 Apr 2010 17:48:36 -0500 (CDT) Subject: APM: Configuring Perl In-Reply-To: References: Message-ID: On Tue, 13 Apr 2010, Montgomery Conner wrote: > You can check the configuration of the currently installed > system-perl with 'perl -V'. This will issue more information than > you ever wanted to know about a Perl install which you could then > use as a template for the new build... Good point! It starts osname=linux, osvers=2.6.9-78.0.1.elsmp, archname=i386-linux-thread-multi uname='linux ls20-bc2-13.build.redhat.com 2.6.9-78.0.1.elsmp #1 smp tue jul 22 18:01:05 edt 2008 i686 athlon i386 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root at localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin' so I guess I could just put those in as ./Configure -des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 ... ... except that's 5.8.8 and I'm building 5.10.1, so there might be some differences in options, for all I know ... -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Tue Apr 13 16:24:54 2010 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Tue, 13 Apr 2010 18:24:54 -0500 Subject: APM: Configuring Perl In-Reply-To: References: Message-ID: If you're in the mood for a good long read there's an INSTALL file distributed with the Perl source. It has very detailed instructions for all of the various build options. But everytime I start to read that document my eyes glaze over and I end up just using the defaults and the auto-discovery provided by Configure... which always seems to just work (with the sole exception being an installation I attempted on an ARM5 Sheeva SoC system running Ubuntu... which required a little TLC ;-) ). On Tue, Apr 13, 2010 at 5:48 PM, Tim McDaniel wrote: > On Tue, 13 Apr 2010, Montgomery Conner > wrote: > > You can check the configuration of the currently installed >> system-perl with 'perl -V'. This will issue more information than >> you ever wanted to know about a Perl install which you could then >> use as a template for the new build... >> > > Good point! It starts > > osname=linux, osvers=2.6.9-78.0.1.elsmp, > archname=i386-linux-thread-multi > uname='linux ls20-bc2-13.build.redhat.com 2.6.9-78.0.1.elsmp #1 smp tue > jul > 22 18:01:05 edt 2008 i686 athlon i386 gnulinux ' > config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 > -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 > -Dmyhostname=localhost -Dperladmin=root at localhost -Dcc=gcc -Dcf_by=Red > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux > -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads > -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm > -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio > -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less > -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto > -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto > -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 > -Dscriptdir=/usr/bin' > > so I guess I could just put those in as > ./Configure -des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > ... > > ... except that's 5.8.8 and I'm building 5.10.1, so there might be > some differences in options, for all I know ... > > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschoate at austin.rr.com Wed Apr 14 05:46:16 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Wed, 14 Apr 2010 7:46:16 -0500 Subject: APM: Perl 5.12.0 is now available Message-ID: <20100414124616.CZST2.186495.root@hrndva-web16-z01> http://www.nntp.perl.org/group/perl.perl5.porters/2010/04/msg158820.html -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- -- From tmcd at panix.com Thu Apr 15 14:44:39 2010 From: tmcd at panix.com (Tim McDaniel) Date: Thu, 15 Apr 2010 16:44:39 -0500 (CDT) Subject: APM: Bugzilla, Perl, server Message-ID: My technical lead is getting immensely frustrated right out of the gate, for the same reasons that were frustrating me. We are looking into installing a late-model Bugzilla on "Red Hat Enterprise Linux Server release 5.3 (Tikanga)". The system will run a few other related programs, like source control and such. Bugzilla is written in Perl (et cetera) and has module dependencies, many of which are not distributed with Perl. There are all sorts of pages with advice like "on a server, always build and maintain your own Perl in a side directory", and "never use CPAN on a system perl where modules are installed by a package manager". So far as I see it, this all makes it a pain in the butt to someone who just wants to install one damned application and use it, and before this my technical lead didn't like Perl anyway. These are the issues I saw: - You should run "perl -V" to get all the compilation options on the system perl (as a hint as to useful or expected features), and use those options on your private Perl, except that in this case the system perl is 5.8.8 and the almost latest perl is 5.10.1, so I don't know that the options are compatible. It seemed a minor pain to specify the side directory and to be sure that it was always being used. - All the Bugzilla Perl scripts start "#! /usr/bin/perl", so you have to stomp on the system perl anyway, or edit every script's top line, and then try to find if any file invokes perl on its own. - To make it possible to unstomp, you have to research and set up /etc/alternatives. In my little bit of looking at /etc/alternatives, it seemed that there are a LOT of slave programs for perl and a lot of complication in it. Anyone with experience in Bugzilla, Perl, and Perl maintenance on a server? -- Tim McDaniel, tmcd at panix.com From montgomery.conner at gmail.com Thu Apr 15 16:49:48 2010 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Thu, 15 Apr 2010 18:49:48 -0500 Subject: APM: Bugzilla, Perl, server In-Reply-To: References: Message-ID: I'm getting the impression that what you really need from Perl is just *dependency support for a single application*: Bugzilla... and that this particular dependency *happens* to be Perl is more-or-less irrelevant. Is that correct? I hate to ask the obvious, but did you RTFM for Bugzilla? I took a quick look and found pertinent documentation about custom installations such as the one you're attempting here: http://www.bugzilla.org/docs/3.6/en/html/nonroot.html. But this really begs the question: If your real need is specifically Bugzilla why don't you simply install an RPM for that software and let it handle it's own dependencies? If it doesn't handle it's own dependencies correctly file a bug ( oh, wait... ;-) ) ... and if there isn't an RPM of a recent enough version of this software available it sounds more like an issue for your OS vendor than Perl. I understand that you're frustrated, but in retrospect I guess I just don't understand the point of all your initial questions about Perl in this context... but maybe I'm missing something. Perl is really just an incidental detail here of the complexity your encountering with a large and proportionately complex piece of *totally unrelated* software... It's like complaining to Sun MicroSystems that you found a big FOSS Java application online that you can't get to work... :-S Issues like this might more productively be directed to specific project mailing lists... for example, Bugzilla's mailing list. Sorry, m On Thu, Apr 15, 2010 at 4:44 PM, Tim McDaniel wrote: > My technical lead is getting immensely frustrated right out of the > gate, for the same reasons that were frustrating me. > > We are looking into installing a late-model Bugzilla on "Red Hat > Enterprise Linux Server release 5.3 (Tikanga)". The system will run a > few other related programs, like source control and such. Bugzilla is > written in Perl (et cetera) and has module dependencies, many of which > are not distributed with Perl. > > There are all sorts of pages with advice like "on a server, always > build and maintain your own Perl in a side directory", and "never use > CPAN on a system perl where modules are installed by a package > manager". > > So far as I see it, this all makes it a pain in the butt to someone > who just wants to install one damned application and use it, and > before this my technical lead didn't like Perl anyway. These are the > issues I saw: > > - You should run "perl -V" to get all the compilation options on the > system perl (as a hint as to useful or expected features), and use > those options on your private Perl, except that in this case the > system perl is 5.8.8 and the almost latest perl is 5.10.1, so I > don't know that the options are compatible. > It seemed a minor pain to specify the side directory and to be sure > that it was always being used. > > - All the Bugzilla Perl scripts start "#! /usr/bin/perl", so you have > to stomp on the system perl anyway, or edit every script's top line, > and then try to find if any file invokes perl on its own. > > - To make it possible to unstomp, you have to research and set up > /etc/alternatives. In my little bit of looking at > /etc/alternatives, it seemed that there are a LOT of slave programs > for perl and a lot of complication in it. > > Anyone with experience in Bugzilla, Perl, and Perl maintenance on a > server? > > -- > Tim McDaniel, tmcd at panix.com > _______________________________________________ > Austin mailing list > Austin at pm.org > http://mail.pm.org/mailman/listinfo/austin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameschoate at austin.rr.com Fri Apr 16 09:09:26 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Fri, 16 Apr 2010 16:09:26 +0000 Subject: APM: Bugzilla, Perl, server In-Reply-To: Message-ID: <20100416160926.K5L8X.336144.root@hrndva-web20-z02> ---- Tim McDaniel wrote: > We are looking into installing a late-model Bugzilla on "Red Hat > Enterprise Linux Server release 5.3 (Tikanga)". The system will run a > few other related programs, like source control and such. Bugzilla is > written in Perl (et cetera) and has module dependencies, many of which > are not distributed with Perl. > > There are all sorts of pages with advice like "on a server, always > build and maintain your own Perl in a side directory", and "never use > CPAN on a system perl where modules are installed by a package > manager". > > So far as I see it, this all makes it a pain in the butt to someone > who just wants to install one damned application and use it, and > before this my technical lead didn't like Perl anyway. These are the > issues I saw: But you're not installing one damn application..."few other related programs". > - You should run "perl -V" to get all the compilation options on the > system perl (as a hint as to useful or expected features), and use > those options on your private Perl, except that in this case the > system perl is 5.8.8 and the almost latest perl is 5.10.1, so I > don't know that the options are compatible. > It seemed a minor pain to specify the side directory and to be sure > that it was always being used. Do you have to have a private Perl? Is there some application dependency that prevents them all from using the latest version? My first goal would be to reduce the grunt work I would have to do maintaining it, and that would be reduce the component count. Have you thought of either a chroot jail or virtualization? > - All the Bugzilla Perl scripts start "#! /usr/bin/perl", so you have > to stomp on the system perl anyway, or edit every script's top line, > and then try to find if any file invokes perl on its own. grep, sed, Perl, etc. This is an automation problem involving pattern matching and replacement. I certainly hope you're not implying you're searching that pile of crap with the mk 1 eyeball... > - To make it possible to unstomp, you have to research and set up > /etc/alternatives. In my little bit of looking at > /etc/alternatives, it seemed that there are a LOT of slave programs > for perl and a lot of complication in it. Seems to me some aliases in the appropriate user account might help resolve some of this. > Anyone with experience in Bugzilla, Perl, and Perl maintenance on a > server? Yes, when I used to work at the IBM LTC, but we ran it on its own box. My fundamental observation is that you're seeing these as problems instead of opportunities to hack the system you 'own'. -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- -- From jameschoate at austin.rr.com Tue Apr 20 06:56:02 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Tue, 20 Apr 2010 13:56:02 +0000 Subject: APM: Confusion Research Center Social Fri. 4-23-10 Message-ID: <20100420135602.LOU1B.234125.root@hrndva-web07-z01> If anybody is interested in talking about hackerspaces or hacking you're welcome to join us, China Buffet 7301 Burnet Rd. #101 7-9 pm Look for the red covered "Applied Cryptography" book. http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- -- From jameschoate at austin.rr.com Thu Apr 29 14:23:58 2010 From: jameschoate at austin.rr.com (jameschoate at austin.rr.com) Date: Thu, 29 Apr 2010 16:23:58 -0500 Subject: APM: FYI: Powerhouse Perl (magazine spec. ed.) Message-ID: <20100429212358.53U6L.356527.root@hrndva-web16-z01> Linux Pro Magazine has released a special edition "Powerhouse Perl" in magazine format. Should be located with the Linux magazines. Has "Powerhouse Perl" as the main byline on the cover. $15.99 and includes a DVD w/ openSuSE 11.2 and Linux Mint 8.0. -- -- -- -- -- Venimus, Vidimus, Dolavimus jameschoate at austin.rr.com james.choate at g.austincc.edu james.choate at twcable.com h: 512-657-1279 w: 512-845-8989 www.ssz.com http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center Adapt, Adopt, Improvise -- -- -- --