From kellert at ohsu.edu Fri Aug 1 21:50:31 2008 From: kellert at ohsu.edu (Thomas Keller) Date: Fri, 1 Aug 2008 21:50:31 -0700 Subject: [Pdx-pm] perl 5.10 installation problem Message-ID: Greetings, I'm running OS X 10.5.4 on an Intel Mac Book. Trying to install perl 5.10 and harness gives the following Failed tests: Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- ../lib/CPANPLUS/Dist/Build/t/02_CPANPLUS- 255 65280 7 3 5-7 ../lib/CPANPLUS/t/01_CPANPLUS-Configure.t 5 1280 296 5 286-288 290- 291 ../lib/CPANPLUS/t/03_CPANPLUS-Internals-S 255 65280 8 7 2-8 ../lib/CPANPLUS/t/04_CPANPLUS-Module.t 255 65280 4 4 1-4 ../lib/CPANPLUS/t/05_CPANPLUS-Internals-F 10 2560 18 10 2 6-7 9-10 12 15-18 ../lib/CPANPLUS/t/07_CPANPLUS-Internals-E 255 65280 1 1 1 ../lib/CPANPLUS/t/08_CPANPLUS-Backend.t 255 65280 7 4 2-4 6 ../lib/CPANPLUS/t/09_CPANPLUS-Internals-S 255 65280 ?? ?? ?? ../lib/CPANPLUS/t/15_CPANPLUS-Shell.t 14 3584 92 14 37-38 40-41 44 47 50 53 74 77 79-80 91-92 ../lib/CPANPLUS/t/19_CPANPLUS-Dist.t 255 65280 6 5 2-6 ../lib/CPANPLUS/t/20_CPANPLUS-Dist-MM.t 255 65280 1 1 1 ../lib/CPANPLUS/t/21_CPANPLUS-Dist-No-Bui 255 65280 2 1 1 ../lib/CPANPLUS/t/30_CPANPLUS-Internals-S 255 65280 25 3 18 24-25 ../lib/CPANPLUS/t/40_CPANPLUS-Internals-R 255 65280 10 1 10 comp/cpp.t ?? ?? ?? run/switchPx.t ?? ?? ?? 76 tests and 725 subtests skipped. Failed 16/1465 test scripts. 59/187414 subtests failed. Files=1465, Tests=187414, 633 wallclock secs (282.87 cusr + 58.47 csys = 341.34 CPU) Failed 16/1465 test programs. 59/187414 subtests failed. ------------------------------------ So to get more information I ran tests individually. Here's one: $ make test TEST_FILES=lib/CPANPLUS/Dist/Build/t and all looked well until the following: Making Hash::Util::FieldHash (dynamic) /Users/kellert/src/perl-5.10.0/ext/Hash/Util/FieldHash PERL=./perl make _test_prep ./miniperl -Ilib uupacktool.pl -u -m cd t && (rm -f ./perl; /bin/ln -s .././perl ./perl) /Users/kellert/src/perl-5.10.0/t PERL=./perl make _test if (true /dev/null 2>&1; then \ make TEST_ARGS= TESTFILE=TEST _test_tty ; \ else \ make TEST_ARGS= TESTFILE=TEST _test_notty ; \ fi cd t && ./perl TEST lib/CPANPLUS/Dist/Build/t From scratchcomputing at gmail.com Sat Aug 2 00:27:42 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sat, 2 Aug 2008 00:27:42 -0700 Subject: [Pdx-pm] perl 5.10 mac installation problem In-Reply-To: References: Message-ID: <200808020027.42827.ewilhelm@cpan.org> # from Thomas Keller # on Friday 01 August 2008 21:50: >So to get more information I ran tests individually. Here's one: >$ make test TEST_FILES=lib/CPANPLUS/Dist/Build/t Sorry, never listen to the blind leader. Read the INSTALL file. The core harness is much more primitive than even EU::MM. cd t; ./perl harness \ ../lib/CPANPLUS/Dist/Build/t/*.t ../lib/CPANPLUS/t/*.t And './perl harness -v $one_test' for the verbose version. I guess all of those macs I see at meetings are really running linux? Do you have a ~/.cpanplus directory? Perhaps mv that and see if there's something in there (or your environment) that's tickling it. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From merlyn at stonehenge.com Sat Aug 2 01:57:08 2008 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Sat, 02 Aug 2008 01:57:08 -0700 Subject: [Pdx-pm] perl 5.10 installation problem In-Reply-To: (Thomas Keller's message of "Fri, 1 Aug 2008 21:50:31 -0700") References: Message-ID: <86bq0baj6j.fsf@blue.stonehenge.com> >>>>> "Thomas" == Thomas Keller writes: Thomas> I'm running OS X 10.5.4 on an Intel Mac Book. Trying to install perl Thomas> 5.10 and harness gives the following Failed tests: I hope you were installing this into a new directory, and not trying to override the installed Perl, which is a Very Very Very Bad idea. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From scratchcomputing at gmail.com Wed Aug 6 17:41:50 2008 From: scratchcomputing at gmail.com (Seven till Seven) Date: Wed, 6 Aug 2008 17:41:50 -0700 Subject: [Pdx-pm] August meeting in one week Message-ID: <200808061741.50391.ewilhelm@cpan.org> Wed. August 13th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Topic: What I Learned, Ate, or Drank during OSCON. Featuring: you! http://pdx.pm.org/kwiki/index.cgi?August2008Meeting This will be an OSCON recap session. We'll probably go around the room a few times with various topics. We will utilize the projector technology in a web 1.999 fashion wherein I click on the links which you put on the wiki page above and you talk for 47 seconds or something. --Eric -- http://pdx.pm.org From scratchcomputing at gmail.com Wed Aug 13 08:22:31 2008 From: scratchcomputing at gmail.com (Seven till Seven) Date: Wed, 13 Aug 2008 08:22:31 -0700 Subject: [Pdx-pm] Meeting Tonight Message-ID: <200808130822.32218.ewilhelm@cpan.org> Wed. August 13th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Topic: What I Learned, Ate, or Drank during OSCON. Featuring: you! http://pdx.pm.org/kwiki/index.cgi?August2008Meeting This will be an OSCON recap session. We'll probably go around the room a few times with various topics. We will utilize the projector technology in a web 1.999 fashion wherein I click on the links which you put on the wiki page above and you talk for 47 seconds or something. --Eric -- http://pdx.pm.org From jaleto at gmail.com Thu Aug 14 00:38:26 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Thu, 14 Aug 2008 00:38:26 -0700 Subject: [Pdx-pm] Odd Test Failures Message-ID: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> Howdy, I have an intermittent failing test. That is, I can run it my test suite many times, but perhaps 10-20% of the time, the same test file will fail, after having passed all the individual tests: ok 6 - success ok 7 - success 1..7 Not an ARRAY reference at /usr/local/lib/perl5/5.10.0/Attribute/Handlers.pm line 185. END failed--call queue aborted. Failed 1/1 test programs. 0/7 subtests failed. Dubious, test returned 2 (wstat 512, 0x200) All 7 subtests passed I have no clue what is touching Attribute::Handlers, I do not use it directly. Has anybody ever run into this? This has intermittently failed on CPANTesters reports, so it is not only happening on my machine. Cheers, -- [---------------------] Jonathan Leto jaleto at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From scratchcomputing at gmail.com Thu Aug 14 01:37:11 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Thu, 14 Aug 2008 01:37:11 -0700 Subject: [Pdx-pm] Odd Test Failures In-Reply-To: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> References: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> Message-ID: <200808140137.11743.ewilhelm@cpan.org> # from Jonathan Leto # on Thursday 14 August 2008 00:38: >Not an ARRAY reference at > /usr/local/lib/perl5/5.10.0/Attribute/Handlers.pm line 185. >... >I have no clue what is touching Attribute::Handlers, I do not use it >directly. If it is not repeatable every time, I would make a copy of Attribute/Handlers.pm and add a croak() at 185 (to replace perl's deref error message.) Unfortunately, mine doesn't seem to have a deref on 185, but I fear you're running into this unchecked eval not returning [$data]. my $evaled = !$raw && eval("package $pkg; no warnings; local \$SIG{__WARN__}=sub{die}; [$data]"); $data = ($evaled && $data =~ /^\s*\[/) ? [$evaled] : ($evaled) ? $evaled : [$data]; So, ugh... croak('gotcha') if(ref($data) ne 'ARRAY')); Then run it as many times as it takes to get a stack trace. (See if you get the same trace each time it fails?) perl -MCarp=verbose -Iblib/{lib,arch} t/your_test.t That is, unless there's some way to get a stacktrace from the builtin deref error -- which would be nifty. --Eric -- "It is impossible to make anything foolproof because fools are so ingenious." --Murphy's Second Corollary --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From pagaltzis at gmx.de Thu Aug 14 03:06:03 2008 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Thu, 14 Aug 2008 12:06:03 +0200 Subject: [Pdx-pm] Odd Test Failures In-Reply-To: <200808140137.11743.ewilhelm@cpan.org> References: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> <200808140137.11743.ewilhelm@cpan.org> Message-ID: <20080814100603.GA13024@klangraum.plasmasturm.org> * Eric Wilhelm [2008-08-14 10:40]: > That is, unless there's some way to get a stacktrace from the > builtin deref error -- which would be nifty. perl -MCarp::Always -Iblib/{lib,arch} t/your_test.t -- *AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1} &Just->another->CPAN->connaisseur; #Aristotle Pagaltzis // From scratchcomputing at gmail.com Thu Aug 14 09:23:36 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Thu, 14 Aug 2008 09:23:36 -0700 Subject: [Pdx-pm] Carp::Always In-Reply-To: <20080814100603.GA13024@klangraum.plasmasturm.org> References: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> <200808140137.11743.ewilhelm@cpan.org> <20080814100603.GA13024@klangraum.plasmasturm.org> Message-ID: <200808140923.36977.ewilhelm@cpan.org> # from Aristotle Pagaltzis # on Thursday 14 August 2008 03:06: >> That is, unless there's some way to get a stacktrace from the >> builtin deref error -- which would be nifty. > >? ? perl -MCarp::Always -Iblib/{lib,arch} t/your_test.t Yes! -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From Peter at PSDT.com Thu Aug 14 11:00:38 2008 From: Peter at PSDT.com (Peter Scott) Date: Thu, 14 Aug 2008 11:00:38 -0700 Subject: [Pdx-pm] Odd Test Failures In-Reply-To: <200808140137.11743.ewilhelm@cpan.org> References: <9aaadf9c0808140038k6acaf259s478747ea838b9e44@mail.gmail.com> <200808140137.11743.ewilhelm@cpan.org> Message-ID: <6.2.3.4.2.20080814105825.033055d0@mail.webquarry.com> At 01:37 AM 8/14/2008, Eric Wilhelm wrote: > >Not an ARRAY reference at > > /usr/local/lib/perl5/5.10.0/Attribute/Handlers.pm line 185. > >... > >I have no clue what is touching Attribute::Handlers, I do not use it > >directly. > >If it is not repeatable every time, I would make a copy of >Attribute/Handlers.pm and add a croak() at 185 (to replace perl's deref >error message.) I'm a fan of the debugger, and would run the program with a conditional breakpoint: $ perl -MAttribute::Handlers -de 0 Loading DB routines from perl5db.pl version 1.3 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. Attribute::Handlers::CODE(0x9dfcd70)(/usr/local/lib/perl5/5.10.0/Attribute/Handlers.pm:221): 221: $global_phase++; DB<1> l 185 185: my ($pkg, $ref, $attr, $data, $raw, $handlerphase, $filename, $linenum) = @$declaration; DB<2> b 185 ref($declaration) ne 'ARRAY' and when it broke there I would inspect the stack and maybe see if I could intuit a value for $declaration that ought to be correct so I could override it and keep going. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From alan at clueserver.org Sat Aug 16 18:13:43 2008 From: alan at clueserver.org (Alan) Date: Sat, 16 Aug 2008 18:13:43 -0700 Subject: [Pdx-pm] ANOUNCEMENT: PLUG Advanced Topics August 20th, 2008 7pm Message-ID: <1218935623.6185.25.camel@rotwang> PLUG Advanced Topics Meeting Date: August 20th, 2008 Time: 7pm - 9pm-ish Location: Jax Bar 826 SW 2nd Ave Portland, OR http://www.jaxbar.com/ Speaker: Jonathan Leto Title: Creating CPAN Modules with SWIG Abstract: This talk will assume a basic familiarity with Perl and C syntax and go through the process of creating a CPAN module which uses the Simplified Wrapper Interface Generator (SWIG) to make an interface to an existing C library. To be used as a "live" example is Math::GSL, a Perl module which is part of the Google Summer of Code 2008 and provides an interface to the GNU Scientific Library. Happy hour food prices for the first hour. Standard meeting rules apply. From chrchr at gmail.com Wed Aug 20 13:29:23 2008 From: chrchr at gmail.com (Robert Church) Date: Wed, 20 Aug 2008 20:29:23 +0000 Subject: [Pdx-pm] Rentrak is hiring Perl developers Message-ID: Hey gang. I'm a developer at Rentrak Corporation. We're one of the largest Perl shops in the Portland area, and we've hired a number of current and former Portland Perl Mongers, including Schwern and Ovid. We're always looking for awesome Perl programmers. You can read all about this position here: http://rentrak.com/section/corporate/careers/software_development.html Thanks. From david at kineticode.com Wed Aug 20 15:38:51 2008 From: david at kineticode.com (David E. Wheeler) Date: Wed, 20 Aug 2008 15:38:51 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: References: Message-ID: <3EAE3245-1A51-47E4-850E-C9A2DD1DAB3B@kineticode.com> On Aug 20, 2008, at 13:29, Robert Church wrote: > Hey gang. I'm a developer at Rentrak Corporation. We're one of the > largest Perl shops in the Portland area, and we've hired a number of > current and former Portland Perl Mongers, including Schwern and Ovid. One should point out that Ovid and Schwern have each worked for Rentrak in the past, but neither of them does now. They didn't work there at the same time, either. Best, David From bruce at drangle.com Wed Aug 20 16:00:26 2008 From: bruce at drangle.com (Bruce Keeler) Date: Wed, 20 Aug 2008 16:00:26 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: References: Message-ID: <48ACA20A.50201@drangle.com> Robert Church wrote: > Hey gang. I'm a developer at Rentrak Corporation. We're one of the > largest Perl shops in the Portland area, and we've hired a number of > current and former Portland Perl Mongers, including Schwern and Ovid. > We're always looking for awesome Perl programmers. > Although I no longer work there, I can heartily recommend the place. Reasonably relaxed work environment, super-smart co-workers, decent code-base, Agile methology, your very own Elvis bust when you break the build. From chrchr at gmail.com Wed Aug 20 18:56:04 2008 From: chrchr at gmail.com (Robert Church) Date: Wed, 20 Aug 2008 18:56:04 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: <48ACA20A.50201@drangle.com> References: <48ACA20A.50201@drangle.com> Message-ID: On Wed, Aug 20, 2008 at 4:00 PM, Bruce Keeler wrote: > Robert Church wrote: >> >> Hey gang. I'm a developer at Rentrak Corporation. We're one of the >> largest Perl shops in the Portland area, and we've hired a number of >> current and former Portland Perl Mongers, including Schwern and Ovid. >> We're always looking for awesome Perl programmers. >> > > Although I no longer work there, I can heartily recommend the place. > Reasonably relaxed work environment, super-smart co-workers, decent > code-base, Agile methology, your very own Elvis bust when you break the > build. Actually, Bruce, the Elvis bust has gone missing. Thanks for the *completely unsolicited* endorsement. From scratchcomputing at gmail.com Thu Aug 21 00:42:28 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Thu, 21 Aug 2008 00:42:28 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: References: <48ACA20A.50201@drangle.com> Message-ID: <200808210042.28256.ewilhelm@cpan.org> # from Robert Church # on Wednesday 20 August 2008 18:56: >>your very own Elvis bust when you break the build. > >Actually, Bruce, the Elvis bust has gone missing. So, the build has left the building? --Eric -- "If you dig it, it's yours." --An old village poet (via Al Pacino) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From publiustemp-pdxpm at yahoo.com Thu Aug 21 15:03:04 2008 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Thu, 21 Aug 2008 15:03:04 -0700 (PDT) Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: <48ACA20A.50201@drangle.com> Message-ID: <664868.35347.qm@web65715.mail.ac4.yahoo.com> --- On Thu, 21/8/08, Bruce Keeler wrote: > Although I no longer work there, I can heartily recommend > the place. > Reasonably relaxed work environment, super-smart > co-workers, decent > code-base, Agile methology, your very own Elvis bust when > you break the > build. I can also recommend them. Great place to work (though their bespoke testing software drove me up a wall :), nice coworkers and some very interesting code to work with. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 From alphanumeric219 at gmail.com Thu Aug 21 14:48:22 2008 From: alphanumeric219 at gmail.com (Andrew H) Date: Thu, 21 Aug 2008 14:48:22 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers Message-ID: Hello, Long time lurker, first-time poster. I have nothing particularly bad to say about Rentrak's employees, but I have a warning for any of those who might consider working there. Last year I came to Portland from out of state to work for Rentrak. I traveled very far to work for them. After a few productive months of working there, they let me go, forcing me into freelance work. Wanting to be a better employee in the future, I tried to get a good explanation as to why. The best answer they could give me was that I was 'too slow', and that there was nothing wrong with the quality of my work. Later, I found out they had hired me on as a vendor, and I'd been misled into thinking I was a full-time employee (be sure to read the paperwork). It was probably my fault, maybe I was too slow, or maybe I didn't fit into the right social niche, but I thought I might share the experience. If just to let you know the level of calibre they are looking for. Anonymous Perl Programmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaleto at gmail.com Thu Aug 21 20:22:28 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Thu, 21 Aug 2008 20:22:28 -0700 Subject: [Pdx-pm] Creating CPAN Modules with SWIG slides Message-ID: <9aaadf9c0808212022s7e5de0des38e6d6f606580969@mail.gmail.com> Howdy, Here are the slides from my talk at the AT/PLUG meeting: PDF: http://leto.net/gitweb/?p=presentations.git;a=blob_plain;f=CreatingCPANModulesWithSWIG/pres.pdf;hb=HEAD LaTeX: http://leto.net/gitweb/?p=presentations.git;a=blob_plain;f=CreatingCPANModulesWithSWIG/pres.tex;hb=HEAD =begin fuel This is not madness. THIS. IS. RENTRAK! =cut Cheers, -- [---------------------] Jonathan Leto jaleto at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at zeroclue.com Thu Aug 21 21:06:45 2008 From: jeff at zeroclue.com (Jeff Lavallee) Date: Thu, 21 Aug 2008 21:06:45 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: References: Message-ID: Well geez, I thought I'd avoid chiming in, but I can't help myself. I worked at Rentrak for 2 years when I first moved to Portland. I had a great experience there - the code base is a pleasure to work with, as were all my co-workers. When I changed jobs recently I was tempted to return. There have been quite a few days in the last 5 years or so that I've wished I stayed. Jeff On Aug 20, 2008, at 1:29 PM, Robert Church wrote: > Hey gang. I'm a developer at Rentrak Corporation. We're one of the > largest Perl shops in the Portland area, and we've hired a number of > current and former Portland Perl Mongers, including Schwern and Ovid. > We're always looking for awesome Perl programmers. > > You can read all about this position here: > > http://rentrak.com/section/corporate/careers/software_development.html > > Thanks. From erik at hollensbe.org Fri Aug 22 05:42:25 2008 From: erik at hollensbe.org (Erik Hollensbe) Date: Fri, 22 Aug 2008 05:42:25 -0700 Subject: [Pdx-pm] Rentrak is hiring Perl developers In-Reply-To: References: Message-ID: <200808220542.25187.erik@hollensbe.org> On Thursday 21 August 2008 21:06:45 Jeff Lavallee wrote: > Well geez, I thought I'd avoid chiming in, but I can't help myself. > > I worked at Rentrak for 2 years when I first moved to Portland. I had > a great experience there - the code base is a pleasure to work with, > as were all my co-workers. When I changed jobs recently I was tempted > to return. There have been quite a few days in the last 5 years or so > that I've wished I stayed. > > > > Jeff > > On Aug 20, 2008, at 1:29 PM, Robert Church wrote: > > Hey gang. I'm a developer at Rentrak Corporation. We're one of the > > largest Perl shops in the Portland area, and we've hired a number of > > current and former Portland Perl Mongers, including Schwern and Ovid. > > We're always looking for awesome Perl programmers. > > > > You can read all about this position here: > > > > http://rentrak.com/section/corporate/careers/software_development.html > > > > Thanks. Any tie breakers? I'm running out of popcorn here. -Erik From jaleto at gmail.com Sat Aug 23 10:56:56 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Sat, 23 Aug 2008 10:56:56 -0700 Subject: [Pdx-pm] Perl header file headache Message-ID: <9aaadf9c0808231056w16e4f835kf28fe7f80e83a689@mail.gmail.com> Howdy, Does anybody know what this is: gcc -I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -c -shared -fpic -I/usr/local/include -Wno-strict-aliasing -Wno-unused-function -Wno-unused-value -Wno-unused-function -Wno-unused-variable -o BLAS_wrap.o BLAS_wrap.c In file included from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/op.h:497, from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perl.h:2754, from BLAS_wrap.c:716: /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/reentr.h:612: error: field '_crypt_struct' has incomplete type In file included from /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/perl.h:3950, from BLAS_wrap.c:716: /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h:297: error: expected declaration specifiers or '...' before 'off64_t' /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h:299: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Perl_do_sysseek' /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h:300: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Perl_do_tell' /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h:2008: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Perl_PerlIO_tell' /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/proto.h:2009: error: expected declaration specifiers or '...' before 'off64_t' This same code has compiled and passed on all kinds of CPANtesters machines, but a user just submitted this compilation error to me personally. This was the problem that I was running into when trying to use Perls older than 5.8.8, but this error is from Perl 5.8.8. Do multi-threaded Perls have different header files? Thank you for any light that you can shed on this situation. Cheers, -- [---------------------] Jonathan Leto jaleto at gmail.com From scratchcomputing at gmail.com Sat Aug 23 11:19:13 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sat, 23 Aug 2008 11:19:13 -0700 Subject: [Pdx-pm] Perl header file headache In-Reply-To: <9aaadf9c0808231056w16e4f835kf28fe7f80e83a689@mail.gmail.com> References: <9aaadf9c0808231056w16e4f835kf28fe7f80e83a689@mail.gmail.com> Message-ID: <200808231119.13098.ewilhelm@cpan.org> # from Jonathan Leto # on Saturday 23 August 2008 10:56: >/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/reentr.h:612: error: >field '_crypt_struct' has incomplete type I dunno, but that looks like the start of the trouble. >This was the problem that I was running into when trying to use Perls >older than 5.8.8, but this error is from Perl 5.8.8. Has this machine successfully built other XS? --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From scratchcomputing at gmail.com Mon Aug 25 20:17:38 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Mon, 25 Aug 2008 20:17:38 -0700 Subject: [Pdx-pm] red hat enterprise "perl" bug Message-ID: <200808252017.38187.ewilhelm@cpan.org> If you happen to be using whatever redhat is calling "perl" lately and haven't seen this yet... http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ https://bugzilla.redhat.com/show_bug.cgi?id=379791 I think Ask said it well: "What is/was RedHat trying to fix with whatever patch to Perl 5.8.8 that introduced this problem?" This was open for almost 9 months? Am I missing something? Everyone running rhel/centos just builds their own Perl, or all of the servers are debian? (BSD?) It might be something you wouldn't notice in day-to-day usage, but a high-volume site with a lot of Perl? If I'm reading correctly, it is only when the return value of bless and overloading interact, but I'm thinking it would only take one module in the critical path running new() really slowly to bring it to the dev/admin's attention. --Eric -- "Because understanding simplicity is complicated." --Eric Raymond --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From andy at petdance.com Mon Aug 25 20:20:37 2008 From: andy at petdance.com (Andy Lester) Date: Mon, 25 Aug 2008 22:20:37 -0500 Subject: [Pdx-pm] red hat enterprise "perl" bug In-Reply-To: <200808252017.38187.ewilhelm@cpan.org> References: <200808252017.38187.ewilhelm@cpan.org> Message-ID: On Aug 25, 2008, at 10:17 PM, Eric Wilhelm wrote: > http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ > > https://bugzilla.redhat.com/show_bug.cgi?id=379791 http://perlbuzz.com/2008/08/red-hats-patch-slows-down-overloading-in-perl.html Run this to illustrate the slowdown, if you have it: #!/usr/bin/perl use Time::HiRes; use overload q(<) => sub {}; my %h; $|++; print "Pass#\tPass time\tTotal time\n"; my $bigstart = Time::HiRes::time(); for my $i ( 1..50 ) { my $start = Time::HiRes::time(); for my $j ( 1..1000 ) { $h{$i*1000 + $j} = bless [ ] => 'main'; } my $now = Time::HiRes::time(); printf( "#%2d\t%f\t%f\n", $i, $now-$start, $now-$bigstart ); } xoxo, Andy -- Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance From jshirley at gmail.com Tue Aug 26 07:47:18 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 07:47:18 -0700 Subject: [Pdx-pm] red hat enterprise "perl" bug In-Reply-To: References: <200808252017.38187.ewilhelm@cpan.org> Message-ID: <756703690808260747m6a74a26dsb665e42783bed68a@mail.gmail.com> On Mon, Aug 25, 2008 at 8:20 PM, Andy Lester wrote: > > On Aug 25, 2008, at 10:17 PM, Eric Wilhelm wrote: > >> http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ >> >> https://bugzilla.redhat.com/show_bug.cgi?id=379791 > > > http://perlbuzz.com/2008/08/red-hats-patch-slows-down-overloading-in-perl.html > > Run this to illustrate the slowdown, if you have it: > > #!/usr/bin/perl > > use Time::HiRes; > use overload q(<) => sub {}; > > my %h; > > $|++; > > print "Pass#\tPass time\tTotal time\n"; > my $bigstart = Time::HiRes::time(); > for my $i ( 1..50 ) { > my $start = Time::HiRes::time(); > for my $j ( 1..1000 ) { > $h{$i*1000 + $j} = bless [ ] => 'main'; > } > my $now = Time::HiRes::time(); > printf( "#%2d\t%f\t%f\n", $i, $now-$start, $now-$bigstart ); > } > > xoxo, > Andy > > -- > Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance > > > > DBIx::Class is affected by this bug (and CDBI, I believe) and causes quite a bit of traffic. We just had someone in #catalyst talking about a significant slowdown on RHEL5 but not RHEL4 when using Opview (Catalyst + CDBI). Friends don't let friends run RHEL vendor perl. From keithl at kl-ic.com Tue Aug 26 09:21:28 2008 From: keithl at kl-ic.com (Keith Lofstrom) Date: Tue, 26 Aug 2008 09:21:28 -0700 Subject: [Pdx-pm] red hat enterprise "perl" bug In-Reply-To: <200808252017.38187.ewilhelm@cpan.org> References: <200808252017.38187.ewilhelm@cpan.org> Message-ID: <20080826162128.GB11743@gate.kl-ic.com> On Mon, Aug 25, 2008 at 08:17:38PM -0700, Eric Wilhelm wrote: > If you happen to be using whatever redhat is calling "perl" lately and > haven't seen this yet... > > http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ > > https://bugzilla.redhat.com/show_bug.cgi?id=379791 > > I think Ask said it well: "What is/was RedHat trying to fix with > whatever patch to Perl 5.8.8 that introduced this problem?" > > This was open for almost 9 months? Am I missing something? Everyone > running rhel/centos just builds their own Perl, or all of the servers > are debian? (BSD?) ... I just posted a message about this to the Scientific Linux email list; the RHEL5 5.8.8 Perl also breaks Math::GSL . If the scientific community reacts as I hope it will, and Red Hat drags their feet, the SL folk may be needing some help from the Perl community to fork the distro to a sane version of Perl. The Scientific Linux distro that I run on all my machines is a slightly forked version of RHEL, mostly with extra features for large compute clusters. There are two people at FermiLab working full time to maintain SL, and a lot of large scientific sites around the world running it. This would be a good opportunity to combine expertise and work together. Mostly, if the Perl community could figure out the answer to Eric's question, and explain to the SL community what the impact of a fix would be (plus and minus), and explain how to test it, then the SL folks could propagate and maintain the fix. It would be nice if Red Hat would fix it, but I imagine they think of Perl as install glue, and I would guess the patch fixes some important part of that, to hell with userspace runtime stuff. Hell, there are not even good tools to merge the RPM system with CPAN, AFAIK. I can provide ssh access to one of my SL5.0 machines running the suspect Perl to trusted individuals who want to experiment with this. Keith -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From ianburrell at gmail.com Tue Aug 26 10:17:47 2008 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 26 Aug 2008 10:17:47 -0700 Subject: [Pdx-pm] red hat enterprise "perl" bug In-Reply-To: <200808252017.38187.ewilhelm@cpan.org> References: <200808252017.38187.ewilhelm@cpan.org> Message-ID: On Mon, Aug 25, 2008 at 8:17 PM, Eric Wilhelm wrote: > > I think Ask said it well: "What is/was RedHat trying to fix with > whatever patch to Perl 5.8.8 that introduced this problem?" > I saw a post by nicholas about the problem [1]. My impression is that this problem was caused by a RedHat-specific patch that was carried over into the 5.8.5 in RHEL 4 and the 5.8.8 in RHEL 5. It sounds like the problem was fixed completely in the official 5.8.7. I am not sure if the slowdown was introduced by the patch, or existed in early versions of 5.8 and the partial patch broke the fixes in 5.8.8. And the real fix was not backported to the RHEL 3 5.8.5. The RHEL 5 5.8.8 is Perl 5.8.8 but with 40 patches applied. - Ian 1: http://use.perl.org/~nicholas/journal/37274 From keithl at kl-ic.com Tue Aug 26 10:27:02 2008 From: keithl at kl-ic.com (Keith Lofstrom) Date: Tue, 26 Aug 2008 10:27:02 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] Message-ID: <20080826172702.GA12221@gate.kl-ic.com> I spoke too soon. Sigh, no distro support on this one. OK, for the complete Perl noob, how does one go about maintaining two versions of Perl on a machine, one for "system" and one for everything else including serving web pages? Understandable, updated, robust and secure is good. I fear the only option is a large learning and maintenance burden. Keith ----- Forwarded message from Connie Sieh ----- X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gate.kl-ic.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=AWL,RCVD_IN_DNSWL_MED autolearn=disabled version=3.2.5 Date: Tue, 26 Aug 2008 11:39:41 -0500 (CDT) From: Connie Sieh Subject: Re: Horribly Broken RHEL5/SL5 Perl In-reply-to: <0K67006QWTPV92 at mailgw2.fnal.gov> To: keithl at keithl.com Cc: SCIENTIFIC-LINUX-USERS at listserv.fnal.gov On Tue, 26 Aug 2008, Keith Lofstrom wrote: >This just in: > >http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ > >Summary: The Upstream Vendor version of Perl has a patch to the >"bless[]" function that makes it /extremely/ slow. Most of us do >not write that kind of of fancy Perl, but a lot of us use one of >the 1500+ CPAN modules that do. The slowdown can be over 100x >with some programs. This affects Fedora 9 as well as the various >version 5 distros. > >TUV-patched Perl version 5.8.8 also breaks the Math::GSL package >that I wrote about a few days ago. It runs fine with 5.10 . > >What to do? Some people are downloading and recompiling Perl; >we have version 5.8.8, while version 5.10 is available . A few >are abandoning Perl. A few are abandoning TUV-inspired distros. >A few are buying way more hardware than they would otherwise need. > >Since some of the scientific community (especially the life sciences) >are running huge amounts of Perl, this is probably a Big Deal. We >should explore the problem further with TUV and the CentOS community. >If a fix is not forthcoming from TUV, I reluctantly suggest that we >get together with the CentOS people and fork this portion of the >distro, perhaps standardizing on Perl 5.10 . There are people >in the Perl community ready to assist us. There is merit in having your own "application" perl vs using the "system" perl for everything. That way you can "decide" . It is NOT a good idea to replace the "system" perl. -Connie Sieh > >Keith > > ----- End forwarded message ----- -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From teknotus at gmail.com Tue Aug 26 10:32:26 2008 From: teknotus at gmail.com (Daniel Johnson) Date: Tue, 26 Aug 2008 10:32:26 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826172702.GA12221@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: On Tue, Aug 26, 2008 at 10:27 AM, Keith Lofstrom wrote: > > I spoke too soon. Sigh, no distro support on this one. OK, > for the complete Perl noob, how does one go about maintaining > two versions of Perl on a machine, one for "system" and one > for everything else including serving web pages? > > Understandable, updated, robust and secure is good. I fear > the only option is a large learning and maintenance burden. > > Keith I'm getting in the habit of building OS packages for things I install from source. That way I can clean them out pretty easily if they break something, and they replace the system version instead of being a secondary install so I'm never in any doubt as to which version is running. From scratchcomputing at gmail.com Tue Aug 26 10:41:00 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Tue, 26 Aug 2008 10:41:00 -0700 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <20080826172702.GA12221@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: <200808261041.00952.ewilhelm@cpan.org> # from Keith Lofstrom # on Tuesday 26 August 2008 10:27: >OK, >for the complete Perl noob, how does one go about maintaining >two versions of Perl on a machine, one for "system" and one >for everything else including serving web pages? You install the source tarball, then use it to install all of the CPAN modules you need. Then, make sure that your applications have /usr/local/bin/perl on the shebang line. I know you're "not supposed to" replace the vendor's perl, but I have to wonder whether rebuilding their SRPM with the actual 5.8.8 source code would really break anything. Would you need to rebuild the binary modules? --Eric -- Atavism n: The recurrence of any peculiarity or disease of an ancestor in a subsequent generation, usually due to genetic recombination. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From pagaltzis at gmx.de Tue Aug 26 10:43:57 2008 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Tue, 26 Aug 2008 19:43:57 +0200 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: <20080826174357.GN32015@klangraum.plasmasturm.org> * Daniel Johnson [2008-08-26 19:35]: > I'm getting in the habit of building OS packages for things I > install from source. That way I can clean them out pretty > easily if they break something, and they replace the system > version instead of being a secondary install so I'm never in > any doubt as to which version is running. Building a package out a local compile is a good idea, but replacing the system perl is not. Build a second perl for your own purposes and leave the system-supplied one completely alone. The reason for this is that (to the extent that they are tested at all!) the packages provided by the vendor are tested against the perl packaged by the vendor. Messing with it puts you on uncharted territory. Regards, -- Aristotle Pagaltzis // From jshirley at gmail.com Tue Aug 26 10:46:33 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 10:46:33 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826172702.GA12221@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> On Tue, Aug 26, 2008 at 10:27 AM, Keith Lofstrom wrote: > > I spoke too soon. Sigh, no distro support on this one. OK, > for the complete Perl noob, how does one go about maintaining > two versions of Perl on a machine, one for "system" and one > for everything else including serving web pages? > > Understandable, updated, robust and secure is good. I fear > the only option is a large learning and maintenance burden. > > Keith > [snip] I would highly recommend looking at local::lib, as it lets you be remarkably flexible not only with multiple perls, but also CPAN and just doing a "perl Makefile.PL && make && make test && make install". The way I do this, and my method is probably not the best for standard usage, is to simply grab a perl I want (lets say perl 5.10) and want to build it in /opt/perl/perl-5.10 Uncompress the tarball, then: ./Configure -des -Dprefix=/opt/perl/perl-5.10 make && make test && make install Now, you have a perl in /opt/perl/perl-5.10 and you can create a symlink in your path, or simply set that in your PATH var. The next important step is to always invoke perl with: #!/usr/bin/env perl Do not use: #!/usr/bin/perl Now, once you have that, follow the instructions for local::lib to get yourself a fully encapsulated dir to install your modules (you can also put this in some other location other than ~/perl5 - read hte pod) Then, invoking your specific non-system perl with env and having a setup local::lib will get you everything you need. Including full CPAN support with nothing breaking, and a fully functional system perl that still resides at /usr/bin/perl (or wherever). Just remember to keep track of which perl you are invoking, but it's really not too difficult to do that. -J From teknotus at gmail.com Tue Aug 26 10:53:41 2008 From: teknotus at gmail.com (Daniel Johnson) Date: Tue, 26 Aug 2008 10:53:41 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826174357.GN32015@klangraum.plasmasturm.org> References: <20080826172702.GA12221@gate.kl-ic.com> <20080826174357.GN32015@klangraum.plasmasturm.org> Message-ID: > Building a package out a local compile is a good idea, but > replacing the system perl is not. Build a second perl for your > own purposes and leave the system-supplied one completely alone. > The reason for this is that (to the extent that they are tested > at all!) the packages provided by the vendor are tested against > the perl packaged by the vendor. Messing with it puts you on > uncharted territory. Well I guess I haven't ever replaced the actual system perl just the modules. But then I've considered Redhat/Fedora/CentOS broken to the point of being barely useable since a short time after I started seriously using Linux. Still though as long as you don't break the package manager (which is unfortunately too easy to do with RPM) you shouldn't have too much trouble reverting to the system perl install in the off chance that a clean perl install breaks something that you can't just fix with a cpan install. From teknotus at gmail.com Tue Aug 26 11:12:39 2008 From: teknotus at gmail.com (Daniel Johnson) Date: Tue, 26 Aug 2008 11:12:39 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> Message-ID: > The next important step is to always invoke perl with: > #!/usr/bin/env perl > Do not use: > #!/usr/bin/perl The /usr/bin/env trick has significant security considerations. Consider a cgi example. http://example.com/cgi/submit.pl?PATH=/tmp Which would run whatever is called perl in the temp directory instead of calling the real perl to compile, and run the cgi script. From teknotus at gmail.com Tue Aug 26 11:48:35 2008 From: teknotus at gmail.com (Daniel Johnson) Date: Tue, 26 Aug 2008 11:48:35 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261116s6bfb7944yb32485cb032db5ae@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <756703690808261116s6bfb7944yb32485cb032db5ae@mail.gmail.com> Message-ID: > What part of the CGI spec or code takes CGI parameters and stores them > in system ENV, before perl is even invoked? Sorry I'm thinking of a PHP "feature". My excuse is that I didn't get enough sleep last night. Still probably many ways to exploit it. Especially if your perl is called from php. From chromatic at wgz.org Tue Aug 26 11:00:50 2008 From: chromatic at wgz.org (chromatic) Date: Tue, 26 Aug 2008 11:00:50 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: <200808261100.50272.chromatic@wgz.org> On Tuesday 26 August 2008 10:32:26 Daniel Johnson wrote: > I'm getting in the habit of building OS packages for things I install > from source. ?That way I can clean them out pretty easily if they > break something, and they replace the system version instead of being > a secondary install so I'm never in any doubt as to which version is > running. Be very careful replacing the system version (where "very careful" means "don't do it!"); if you change the installation significantly, you can render certain system tools inoperable and break your machine. -- c From pagaltzis at gmx.de Tue Aug 26 11:50:46 2008 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Tue, 26 Aug 2008 20:50:46 +0200 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> Message-ID: <20080826185046.GO32015@klangraum.plasmasturm.org> * Daniel Johnson [2008-08-26 20:15]: > > The next important step is to always invoke perl with: > > #!/usr/bin/env perl > > Do not use: > > #!/usr/bin/perl > > The /usr/bin/env trick has significant security considerations. > Consider a cgi example. > > http://example.com/cgi/submit.pl?PATH=/tmp > > Which would run whatever is called perl in the temp directory > instead of calling the real perl to compile, and run the cgi > script. Not hardly, at least not with any sane web server. CGI is not PHP. All you will manage to do with that `PATH=/tmp` query string is to, well, put `PATH=/tmp` in the `QUERY_STRING` environment variable. You will most emphatically *NOT* manage to put `/tmp` in the `PATH` variable ? unless you?re using an insane web server that actually implements CGI that way. But then the problem is still not on the Perl script?s shebang line. That said, your basic point is quite correct: using `env` on a system with multiple perls is unwise, as it introduces a random external influence on which perl will execute. Regards, -- Aristotle Pagaltzis // From erik at hollensbe.org Tue Aug 26 11:44:28 2008 From: erik at hollensbe.org (Erik Hollensbe) Date: Tue, 26 Aug 2008 11:44:28 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> Message-ID: <200808261144.30260.erik@hollensbe.org> On Tuesday 26 August 2008 11:12:39 Daniel Johnson wrote: > > The next important step is to always invoke perl with: > > #!/usr/bin/env perl > > Do not use: > > #!/usr/bin/perl > > The /usr/bin/env trick has significant security considerations. > Consider a cgi example. > > http://example.com/cgi/submit.pl?PATH=/tmp > > Which would run whatever is called perl in the temp directory instead > of calling the real perl to compile, and run the cgi script. What CGI library shoves the parameters from GET/POST directly into the environment? Or is that some part of the spec I wasn't aware of? -Erik From jshirley at gmail.com Tue Aug 26 12:16:06 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 12:16:06 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826185046.GO32015@klangraum.plasmasturm.org> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> Message-ID: <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> On Tue, Aug 26, 2008 at 11:50 AM, Aristotle Pagaltzis wrote: > * Daniel Johnson [2008-08-26 20:15]: >> > The next important step is to always invoke perl with: >> > #!/usr/bin/env perl >> > Do not use: >> > #!/usr/bin/perl >> >> The /usr/bin/env trick has significant security considerations. >> Consider a cgi example. >> >> http://example.com/cgi/submit.pl?PATH=/tmp >> >> Which would run whatever is called perl in the temp directory >> instead of calling the real perl to compile, and run the cgi >> script. > > Not hardly, at least not with any sane web server. CGI is not > PHP. All you will manage to do with that `PATH=/tmp` query string > is to, well, put `PATH=/tmp` in the `QUERY_STRING` environment > variable. You will most emphatically *NOT* manage to put `/tmp` > in the `PATH` variable ? unless you're using an insane web server > that actually implements CGI that way. But then the problem is > still not on the Perl script's shebang line. > > That said, your basic point is quite correct: using `env` on a > system with multiple perls is unwise, as it introduces a random > external influence on which perl will execute. > > Regards, > -- > Aristotle Pagaltzis // I really wouldn't call it "random" - it is external influence, but that is somewhat the point of having multiple perls. If we're talking about a single replacement for your system perl it probably isn't necessary. If you truly want multiple perls, in my opinion env is the best way to manage it. (And now I'm just more thankful that I do not deal with PHP... no wonder so many PHP sites are exploited) From Peter at PSDT.com Tue Aug 26 12:32:17 2008 From: Peter at PSDT.com (Peter Scott) Date: Tue, 26 Aug 2008 12:32:17 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826172702.GA12221@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> Message-ID: <6.2.3.4.2.20080826122840.0326bc10@mail.webquarry.com> At 10:27 AM 8/26/2008, you wrote: >I spoke too soon. Sigh, no distro support on this one. OK, >for the complete Perl noob, how does one go about maintaining >two versions of Perl on a machine, one for "system" and one >for everything else including serving web pages? > >Understandable, updated, robust and secure is good. I fear >the only option is a large learning and maintenance burden. I leave the system Perl completely alone on every system. I figure that if the vendor wants it there, they have a reason, and I am not going to risk breaking something by playing with it, especially since I am going to want all kinds of things that they did not, like debugging support, threading, etc. I leave all changes to the system perl to package upgrades from the vendor and I build /usr/local/bin/perl from source with just 'configure -des' etc and then put /usr/local/bin first in my path so everything I do gets the perl I want. Never had a problem with this approach. FWIW, the Fedora Core 5 Perl 5.8.8 does not have the bless() problem on my system. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From gpetme at gmail.com Tue Aug 26 13:17:00 2008 From: gpetme at gmail.com (Greg Petras) Date: Tue, 26 Aug 2008 13:17:00 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> Message-ID: On Tue, Aug 26, 2008 at 12:16 PM, J. Shirley wrote: [snip] > If you truly want multiple perls, in my opinion env is the best way to > manage it. I disagree. There's a variety of more secure ways to do this, in my opinion. The prefix where Perl is installed is irrelevant (as everyone seems to do it their own way), but why not be explicit, and set the absolute path to Perl? #!/usr/blah/bin/perl seems the best to me. Greg From chromatic at wgz.org Tue Aug 26 11:33:55 2008 From: chromatic at wgz.org (chromatic) Date: Tue, 26 Aug 2008 11:33:55 -0700 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <200808261041.00952.ewilhelm@cpan.org> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> Message-ID: <200808261133.55108.chromatic@wgz.org> On Tuesday 26 August 2008 10:41:00 Eric Wilhelm wrote: > I know you're "not supposed to" replace the vendor's perl, but I have to > wonder whether rebuilding their SRPM with the actual 5.8.8 source code > would really break anything. ?Would you need to rebuild the binary > modules? The answer depends on the differences between the two Perl binaries. -- c From jshirley at gmail.com Tue Aug 26 13:52:11 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 13:52:11 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> Message-ID: <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> On Tue, Aug 26, 2008 at 1:17 PM, Greg Petras wrote: > On Tue, Aug 26, 2008 at 12:16 PM, J. Shirley wrote: > [snip] >> If you truly want multiple perls, in my opinion env is the best way to >> manage it. > > I disagree. There's a variety of more secure ways to do this, in my > opinion. The prefix where Perl is installed is irrelevant (as everyone > seems to do it their own way), but why not be explicit, and set the > absolute path to Perl? > > #!/usr/blah/bin/perl seems the best to me. > > Greg > And then when you want to run or change your perl for your application in a controlled manner, you modify your paths in every script? If you happen to miss one, you run an inconsistent environment? If you're not managing your paths in your application and production environments, you can't claim that you are being "more secure". You're simply being vague and hoping for the best. If you have explicit paths, then you are -more- secure because you know EXACTLY what is going into your path before any code execution. This is simply another point where env wins. It's programmatic, reproducible and completely explicit. -J From gpetme at gmail.com Tue Aug 26 14:41:18 2008 From: gpetme at gmail.com (Greg Petras) Date: Tue, 26 Aug 2008 14:41:18 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> Message-ID: On Tue, Aug 26, 2008 at 1:52 PM, J. Shirley wrote: [snip] > And then when you want to run or change your perl for your application > in a controlled manner, you modify your paths in every script? If you > happen to miss one, you run an inconsistent environment? This is what QA and controlled builds are for, no? I guess it could be argued either way - either put the path to the perl interpreter in your build scripts or put the profile settings in the build scripts. Is env "how it's done"? I'm relatively new to Perl (last 5 years), so it'd be nice to hear from some others on how they do things. > If you're not managing your paths in your application and production > environments, you can't claim that you are being "more secure". You're > simply being vague and hoping for the best. Being explicit with a #!/path/to/perl is not vague, in my opinion. Greg From pagaltzis at gmx.de Tue Aug 26 15:00:10 2008 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Wed, 27 Aug 2008 00:00:10 +0200 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> Message-ID: <20080826220010.GQ32015@klangraum.plasmasturm.org> * J. Shirley [2008-08-26 22:55]: > And then when you want to run or change your perl for your > application in a controlled manner, you modify your paths > in every script? Few people with their wits about them would choose to do it this way, but err, how many people with their wits about them would move their perls around often enough that this would matter in the first place? Regards, -- Aristotle Pagaltzis // From jshirley at gmail.com Tue Aug 26 14:59:41 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 14:59:41 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> Message-ID: <756703690808261459s7b59325dw88aeb0d84d5cdc0c@mail.gmail.com> On Tue, Aug 26, 2008 at 2:41 PM, Greg Petras wrote: > On Tue, Aug 26, 2008 at 1:52 PM, J. Shirley wrote: > [snip] >> And then when you want to run or change your perl for your application >> in a controlled manner, you modify your paths in every script? If you >> happen to miss one, you run an inconsistent environment? > > This is what QA and controlled builds are for, no? I guess it could be > argued either way - either put the path to the perl interpreter in > your build scripts or put the profile settings in the build scripts. > Is env "how it's done"? I'm relatively new to Perl (last 5 years), so > it'd be nice to hear from some others on how they do things. > (Sorry for the spam, Greg! I'm used to ml's setting reply-to... *thin excuse!*) If QA can catch everything, sure. I wouldn't bet on it. Controlled builds should setup the proper production environment, which could be a single-use, version specific perl build plus modules: /opt/Application-$VERSION/bin Then you setup your PATH = be that, and you don't have to do any monkeying around. Again, the usefulness of this only shines when you -need- multiple perls. When that need arises, /usr/bin/env can't be beaten out as the "right" choice. >> If you're not managing your paths in your application and production >> environments, you can't claim that you are being "more secure". You're >> simply being vague and hoping for the best. > > Being explicit with a #!/path/to/perl is not vague, in my opinion. > The only thing "explicit" is which perl interpreter you are invoking, which to me does seem much more vague (is it real, a symlink, who knows?). Unless your build puts the path to the perl interpreter there, you're taking something for granted (and thus, is vague). mst, the author of local::lib and many other very very good packages, and generally big braned dude with a chainsaw, probably has a lot of more cohesive arguments than I do about /usr/bin/env. I'm trying to pester him to write up an article on it... hopefully we can see it. -J -- J. Shirley :: jshirley at gmail.com :: Killing two stones with one bird... http://www.toeat.com From teknotus at gmail.com Tue Aug 26 15:05:33 2008 From: teknotus at gmail.com (Daniel Johnson) Date: Tue, 26 Aug 2008 15:05:33 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> Message-ID: > (And now I'm just more thankful that I do not deal with PHP... no > wonder so many PHP sites are exploited) Actually PHP is much worse. In PHP 4, and earlier the default is... http://example.com?foo=bar effectively does my foo = bar; in package main Combined with other PHP options you can read/write/execute all kinds of stuff. From jshirley at gmail.com Tue Aug 26 15:08:38 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 15:08:38 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826220010.GQ32015@klangraum.plasmasturm.org> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> <20080826220010.GQ32015@klangraum.plasmasturm.org> Message-ID: <756703690808261508t2558d765x30e68e3c54487211@mail.gmail.com> On Tue, Aug 26, 2008 at 3:00 PM, Aristotle Pagaltzis wrote: > * J. Shirley [2008-08-26 22:55]: >> And then when you want to run or change your perl for your >> application in a controlled manner, you modify your paths >> in every script? > > Few people with their wits about them would choose to do it this > way, but err, how many people with their wits about them would > move their perls around often enough that this would matter in > the first place? > > Regards, > -- > Aristotle Pagaltzis // Ok, then please enlighten me on how you would have an clean room environment for production or testing of each build? #!/opt/sandbox-1.0/bin/perl and then perl -p -i -e at every version change? I couldn't care less about what people with their wits about them do, I blame that for the popularity of PHP. I care about what works and is programmatic, reproducible, clean, easy to document and understand, that -may- have the potential for a security hole but only if there is unrestricted access to the application. -J From scratchcomputing at gmail.com Tue Aug 26 15:38:53 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Tue, 26 Aug 2008 15:38:53 -0700 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <200808261133.55108.chromatic@wgz.org> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> <200808261133.55108.chromatic@wgz.org> Message-ID: <200808261538.53136.ewilhelm@cpan.org> # from chromatic # on Tuesday 26 August 2008 11:33: >> whether rebuilding their SRPM with the actual 5.8.8 source code >> would really break anything. ?Would you need to rebuild the binary >> modules? > >The answer depends on the differences between the two Perl binaries. Yes, but we're talking about what is *supposed* to be the same source tree. As I understand it, anything linked against the libperl.so would continue working so long as they aren't calling some now-non-existent function. Am I understanding the shared object files correctly? If so, wouldn't one of the RHerl patches have to remove a function for this to cause breakage? Yes some ifdefs would remove functions, but we were going to use the SRPM, which should mean getting the same configure options, right? --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From chromatic at wgz.org Tue Aug 26 12:51:14 2008 From: chromatic at wgz.org (chromatic) Date: Tue, 26 Aug 2008 12:51:14 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> Message-ID: <200808261251.15001.chromatic@wgz.org> On Tuesday 26 August 2008 11:12:39 Daniel Johnson wrote: > > The next important step is to always invoke perl with: > > #!/usr/bin/env perl > > Do not use: > > #!/usr/bin/perl > The /usr/bin/env trick has significant security considerations. > Consider a cgi example. > > http://example.com/cgi/submit.pl?PATH=/tmp > > Which would run whatever is called perl in the temp directory instead > of calling the real perl to compile, and run the cgi script. How do you have your webserver coonfigured such that that's an issue? I've never seen query parameters put into %ENV. -- c From keithl at kl-ic.com Tue Aug 26 16:40:10 2008 From: keithl at kl-ic.com (Keith Lofstrom) Date: Tue, 26 Aug 2008 16:40:10 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> Message-ID: <20080826234010.GA14132@gate.kl-ic.com> On Tue, Aug 26, 2008 at 10:27 AM, Keith Lofstrom wrote: > I spoke too soon. Sigh, no distro support on this one. OK, > for the complete Perl noob, how does one go about maintaining > two versions of Perl on a machine, one for "system" and one > for everything else including serving web pages? > > Understandable, updated, robust and secure is good. I fear > the only option is a large learning and maintenance burden. On Tue, Aug 26, 2008 at 10:46:33AM -0700, J. Shirley wrote: > I would highly recommend looking at local::lib, ... > to build it in /opt/perl/perl-5.10 ... Good stuff! Everyone agrees with maintaining 2+ Perls, and I now understand the wisdom of that. I'm not so convinced by the env approach, or using /opt for the alternate Perl. Others point to writing the scripts with #!/usr/local/bin/perl . Since I am not a developer, merely a user crawling through no-man's-land between the Red Hat and Perl trenches, I hope I can come up with something that is easy to maintain and understand without getting my butt shot off by third-party cybersociopaths as I crawl along. Based on what has been posted so far, my inclination is to keep it simple and use the hard-path /usr/local/bin/perl approach for all my local and CGI scripts. Then I figure out some way to keep the modules current and secure, since I will now be dating outside my distro and its automated update process. If there are any books or articles or documentation with cookbook-ish formulas for doing this mostly correctly, I would welcome some pointers. I am in awe of the adept chainsaw juggling practiced by the wizards of Perl, but it is not something I want to try at home. Keith -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From jaleto at gmail.com Tue Aug 26 17:07:19 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Tue, 26 Aug 2008 17:07:19 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <756703690808261508t2558d765x30e68e3c54487211@mail.gmail.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826185046.GO32015@klangraum.plasmasturm.org> <756703690808261216wfc8b6cckd9b436210610d0fd@mail.gmail.com> <756703690808261352u8bc9b1dj27d6bf7944595d33@mail.gmail.com> <20080826220010.GQ32015@klangraum.plasmasturm.org> <756703690808261508t2558d765x30e68e3c54487211@mail.gmail.com> Message-ID: <9aaadf9c0808261707x428bef29y7d7fa68a41e66d55@mail.gmail.com> Howdy, Rentrak has many different development projects which each uses it's own build of Perl on top various internal Perl modules, which may or may not come from different subversion repos, live on different filesystems, etc. Each has different databases/minimum module versions/supported Perl versions/etc. The way we deal with this is: #!/usr/bin/foo_perl use TheRightLibs 'foo'; Where TheRightLibs is a simple module which gets the properties associated with subsystem 'foo' ( stored in another Perl module) and requires them into the current namespace. This can include fiddling with @INC, %ENV, whateva'. Thus, each subsystem has a canonical place where settings can be changed and no scripts or shebang lines or environment variables need to be changed. Each subsystem has it's own perl and this is explicitly used on the shebang line of every script that is part of that subsystem. If you wanted to change the password or the name of the database or whatever for every script in subsystem 'foo', all you do is change the associated properties module and then *poof*, magically delicious. I think this method has all of the features you want without the insecurity of "env perl". Cheers, > I couldn't care less about what people with their wits about them do, > I blame that for the popularity of PHP. I care about what works and > is programmatic, reproducible, clean, easy to document and understand, > that -may- have the potential for a security hole but only if there is > unrestricted access to the application. -- [---------------------] Jonathan Leto jaleto at gmail.com From tex at off.org Tue Aug 26 17:53:40 2008 From: tex at off.org (Austin Schutz) Date: Tue, 26 Aug 2008 17:53:40 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826234010.GA14132@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826234010.GA14132@gate.kl-ic.com> Message-ID: <20080827005339.GN12200@gblx.net> On Tue, Aug 26, 2008 at 04:40:10PM -0700, Keith Lofstrom wrote: > Based on what has been posted so far, my inclination is to keep it > simple and use the hard-path /usr/local/bin/perl approach for all > my local and CGI scripts. Then I figure out some way to keep the > modules current and secure, since I will now be dating outside > my distro and its automated update process. If there are any > books or articles or documentation with cookbook-ish formulas > for doing this mostly correctly, I would welcome some pointers. > I am in awe of the adept chainsaw juggling practiced by the > wizards of Perl, but it is not something I want to try at home. > Another fun thing is when your applications depend on specific versions of its modules. Now you get to have separate perls for each application, or hope that nothing breaks when you upgrade them. I've found it to be good enough to point apps at version specific perls, but I'm not sure there's a good answer for this globally. Austin From scratchcomputing at gmail.com Tue Aug 26 18:43:14 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Tue, 26 Aug 2008 18:43:14 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826234010.GA14132@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826234010.GA14132@gate.kl-ic.com> Message-ID: <200808261843.15049.ewilhelm@cpan.org> # from Keith Lofstrom # on Tuesday 26 August 2008 16:40: >Then I figure out some way to keep the >modules current and secure, since I will now be dating outside >my distro and its automated update process. Yes. I'm not sure what sort of security enhancements you were getting from the RPMs, but the main thing you notice when installing directly from CPAN is that the latest and greatest is always assumed to be stable. You can request a specific (older or alpha) tarball by using the "$AUTHOR/Foo-Bar-$version.tar.gz" name instead of just "Foo::Bar". That means you would have to go through the dependencies in bottom-up order though if you wanted to peg to e.g. all of the versions your RPMs had. --Eric -- "It works better if you plug it in!" --Sattinger's Law --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From jshirley at gmail.com Tue Aug 26 19:37:28 2008 From: jshirley at gmail.com (J. Shirley) Date: Tue, 26 Aug 2008 19:37:28 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826234010.GA14132@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826234010.GA14132@gate.kl-ic.com> Message-ID: <756703690808261937s730fa95fn2afa5b9d874ce83b@mail.gmail.com> On Tue, Aug 26, 2008 at 4:40 PM, Keith Lofstrom wrote: > On Tue, Aug 26, 2008 at 10:27 AM, Keith Lofstrom wrote: > >> I spoke too soon. Sigh, no distro support on this one. OK, >> for the complete Perl noob, how does one go about maintaining >> two versions of Perl on a machine, one for "system" and one >> for everything else including serving web pages? >> >> Understandable, updated, robust and secure is good. I fear >> the only option is a large learning and maintenance burden. > > On Tue, Aug 26, 2008 at 10:46:33AM -0700, J. Shirley wrote: > >> I would highly recommend looking at local::lib, > ... >> to build it in /opt/perl/perl-5.10 > ... > > Good stuff! Everyone agrees with maintaining 2+ Perls, and I > now understand the wisdom of that. I'm not so convinced by > the env approach, or using /opt for the alternate Perl. Others > point to writing the scripts with #!/usr/local/bin/perl . Since I > am not a developer, merely a user crawling through no-man's-land > between the Red Hat and Perl trenches, I hope I can come up with > something that is easy to maintain and understand without getting > my butt shot off by third-party cybersociopaths as I crawl along. > > Based on what has been posted so far, my inclination is to keep it > simple and use the hard-path /usr/local/bin/perl approach for all > my local and CGI scripts. Then I figure out some way to keep the > modules current and secure, since I will now be dating outside > my distro and its automated update process. If there are any > books or articles or documentation with cookbook-ish formulas > for doing this mostly correctly, I would welcome some pointers. > I am in awe of the adept chainsaw juggling practiced by the > wizards of Perl, but it is not something I want to try at home. > > Keith > Just to clear up a few points about my position with env and /opt (before the thread fades away), if you know you are only going to deal with two perl binaries and that is it the usage of env doesn't really get you anything. I find it easier to err on the side of expandability, and set things up in a way that gets me the most flexibility in the longer term, but I also work in environments that typically require different environments. The reason for putting custom perl builds in /opt is that I view it as an add-on dependency for whatever application. This method fits in with the UNIX idea of /opt, and here's a quote as to why I came to that conclusion: Purpose /opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name. __END__ So, the way that I see it is that shoving everything in an /opt/{package} dir is an easier way of figuring out exactly where my applications dependencies are. It does require a bit more manual tweaking of the environment, but I find manually tweaking the environment is well worth it in these cases. It also means that you can just tar up an entire directory, and send it to production hosts and not have to deal with CPAN installing different versions, etc. If you scatter files in /usr/local/bin and /usr/local/lib/perl it gets a bit harder to do that. I am very curious how the various cpantesters setup their various perls for smoking, though. -J From scratchcomputing at gmail.com Tue Aug 26 20:05:50 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Tue, 26 Aug 2008 20:05:50 -0700 Subject: [Pdx-pm] CPAN updates vs vendor updates In-Reply-To: <20080827024127.GA14948@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261843.15049.ewilhelm@cpan.org> <20080827024127.GA14948@gate.kl-ic.com> Message-ID: <200808262005.50978.ewilhelm@cpan.org> # from Keith Lofstrom # on Tuesday 26 August 2008 19:41: >> Yes. ?I'm not sure what sort of security enhancements you were >> getting from the RPMs, but the main thing you notice when installing >> directly from CPAN is that the latest and greatest is always assumed >> to be stable. ... > >Shudder. ?The usual distro updates are to fix exploitable security >holes or repair disabling bugs, but to not add features or improve >performance. ?Some regression testing is implied. ?I assume that >some CPAN modules are barely tested and there is little preventing >them from having more bugs and security holes than their predecessors; >some may even be nonfunctional. Well, you're assuming that your vendor has done extensive compatibility testing on all of the perl modules. You can lookup a module's results on cpantesters. http://cpantesters.perl.org/show/Math-GSL.html Now, that only gives you the OK for all of the current states of the dependencies (as found on CPAN at the time of the test), but that tends to keep things in a working state for the case of "If I startup CPAN.pm on a fresh install, it will pass." Of course, if redhat had added a critical security patch to a module without pushing the change upstream, you might get to be the sharp-eyed consumer who caught them out at it ;-) --Eric -- "I've often gotten the feeling that the only people who have learned from computer assisted instruction are the authors." --Ben Schneiderman --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From allison at perl.org Wed Aug 27 01:18:43 2008 From: allison at perl.org (Allison Randal) Date: Wed, 27 Aug 2008 10:18:43 +0200 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <200808261133.55108.chromatic@wgz.org> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> <200808261133.55108.chromatic@wgz.org> Message-ID: <48B50DE3.7060806@perl.org> chromatic wrote: > On Tuesday 26 August 2008 10:41:00 Eric Wilhelm wrote: > >> I know you're "not supposed to" replace the vendor's perl, but I have to >> wonder whether rebuilding their SRPM with the actual 5.8.8 source code >> would really break anything. Would you need to rebuild the binary >> modules? > > The answer depends on the differences between the two Perl binaries. Honestly, there's no benefit to replacing the vendor's perl, and huge risk. If you compile your perl in some custom location (/usr/local or /opt/perl), and make sure it knows to respond to '#!/usr/bin/perl' on the shebang line (it's a configuration option when compiling perl, the shebang line doesn't have to match the path), then all you have to do is change your PATH environment variable so /usr/local/bin (or /opt/perl/5.8.8/bin) comes before /usr/bin, and you'll always get your compiled perl instead of the vendor's perl, while the rest of the system will get the vendor's perl. Allison From erik at hollensbe.org Wed Aug 27 02:05:22 2008 From: erik at hollensbe.org (Erik Hollensbe) Date: Wed, 27 Aug 2008 02:05:22 -0700 Subject: [Pdx-pm] [csieh@fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl] In-Reply-To: <20080826234010.GA14132@gate.kl-ic.com> References: <20080826172702.GA12221@gate.kl-ic.com> <756703690808261046q7476a0akce7a231574b4a099@mail.gmail.com> <20080826234010.GA14132@gate.kl-ic.com> Message-ID: <200808270205.22654.erik@hollensbe.org> On Tuesday 26 August 2008 16:40:10 Keith Lofstrom wrote: > Good stuff! Everyone agrees with maintaining 2+ Perls, and I > now understand the wisdom of that. I'm not so convinced by > the env approach, or using /opt for the alternate Perl. Others > point to writing the scripts with #!/usr/local/bin/perl . Since I > am not a developer, merely a user crawling through no-man's-land > between the Red Hat and Perl trenches, I hope I can come up with > something that is easy to maintain and understand without getting > my butt shot off by third-party cybersociopaths as I crawl along. Keith, another (perhaps better for your situation, perhaps not) alternative is how FreeBSD approaches this problem. At least in older versions of FreeBSD, there was a system perl that was required for system interaction and that version was fixed. If you wanted a newer perl, you had to install it from ports. However, as you might encounter by using location-specific shebangs (as opposed to leveraging the path via /usr/bin/env), lots of vendor scripts use /usr/bin/perl as if it's always supposed to be there. On older versions (as in, two years ago) of FreeBSD, that meant you were using 5.005, which is just over 10 years old. Probably not what you want. Also, it may be the case that editing every perl script you install outside of CPAN is taking 'time consuming' to a whole new level. Anyways, the FreeBSD guys came up with a little selector tool called 'use.perl', which selected what /usr/bin/perl pointed at in certain situations. I wish I could give you exact details of the implementation, but it's probably worth looking into should you run into this problem. It would probably require repackaging (which is safe as long as you preserve the modifications and build process) your system perl to muck with the path of the "real" perl binary, and installing a script or symlink in it's place. If you have many machines to maintain, this may be the simplest route, as much as it may not read like it. HTH, -Erik From Peter at PSDT.com Wed Aug 27 09:08:09 2008 From: Peter at PSDT.com (Peter Scott) Date: Wed, 27 Aug 2008 09:08:09 -0700 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <48B50DE3.7060806@perl.org> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> <200808261133.55108.chromatic@wgz.org> <48B50DE3.7060806@perl.org> Message-ID: <6.2.3.4.2.20080827090722.037d9eb0@mail.webquarry.com> At 01:18 AM 8/27/2008, Allison Randal wrote: >If you compile your perl in some custom location (/usr/local or >/opt/perl), and make sure it knows to respond to '#!/usr/bin/perl' on >the shebang line (it's a configuration option when compiling perl, the >shebang line doesn't have to match the path), What option is that? I'm only familiar with the one that tells it to overwrite /usr/bin/perl in addition to building somewhere else. >then all you have to do is change your PATH environment variable so >/usr/local/bin (or /opt/perl/5.8.8/bin) comes before /usr/bin, and >you'll always get your compiled perl instead of the vendor's perl, >while the rest of the system will get the vendor's perl. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From allison at perl.org Wed Aug 27 09:40:42 2008 From: allison at perl.org (Allison Randal) Date: Wed, 27 Aug 2008 18:40:42 +0200 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <6.2.3.4.2.20080827090722.037d9eb0@mail.webquarry.com> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> <200808261133.55108.chromatic@wgz.org> <48B50DE3.7060806@perl.org> <6.2.3.4.2.20080827090722.037d9eb0@mail.webquarry.com> Message-ID: <48B5838A.2080409@perl.org> Peter Scott wrote: > At 01:18 AM 8/27/2008, Allison Randal wrote: >> If you compile your perl in some custom location (/usr/local or >> /opt/perl), and make sure it knows to respond to '#!/usr/bin/perl' on >> the shebang line (it's a configuration option when compiling perl, the >> shebang line doesn't have to match the path), > > What option is that? I'm only familiar with the one that tells it to > overwrite /usr/bin/perl in addition to building somewhere else. I don't know the Configure flag, because I always use the interactive configuration (I always compile perl for myself, because I never install modules using CPAN.pm on a vendor install of perl, and vendor distribution systems never have all the modules I need): Installation prefix to use? (~name ok) [/opt/perl/5.8.8] [...] Do you want to install perl as /usr/bin/perl? [n] [...] I can use the #! construct to start perl on your system. This will make startup of perl scripts faster, but may cause problems if you want to share those scripts and perl is not in a standard place (/opt/perl/5.8.8/bin/perl) on all your platforms. The alternative is to force a shell by starting the script with a single ':' character. What shall I put after the #! to start up perl ("none" to not use #!)? [/opt/perl/5.8.8/bin/perl] (Which I always change to /usr/bin/perl.) Allison From jshirley at gmail.com Wed Aug 27 10:08:03 2008 From: jshirley at gmail.com (J. Shirley) Date: Wed, 27 Aug 2008 10:08:03 -0700 Subject: [Pdx-pm] maintaining your own perl tree In-Reply-To: <48B5838A.2080409@perl.org> References: <20080826172702.GA12221@gate.kl-ic.com> <200808261041.00952.ewilhelm@cpan.org> <200808261133.55108.chromatic@wgz.org> <48B50DE3.7060806@perl.org> <6.2.3.4.2.20080827090722.037d9eb0@mail.webquarry.com> <48B5838A.2080409@perl.org> Message-ID: <756703690808271008x5af223a9gc40a2552a234e93e@mail.gmail.com> On Wed, Aug 27, 2008 at 9:40 AM, Allison Randal wrote: > Peter Scott wrote: >> >> At 01:18 AM 8/27/2008, Allison Randal wrote: >>> >>> If you compile your perl in some custom location (/usr/local or >>> /opt/perl), and make sure it knows to respond to '#!/usr/bin/perl' on the >>> shebang line (it's a configuration option when compiling perl, the shebang >>> line doesn't have to match the path), >> >> What option is that? I'm only familiar with the one that tells it to >> overwrite /usr/bin/perl in addition to building somewhere else. > > I don't know the Configure flag, because I always use the interactive > configuration (I always compile perl for myself, because I never install > modules using CPAN.pm on a vendor install of perl, and vendor distribution > systems never have all the modules I need): > > Installation prefix to use? (~name ok) [/opt/perl/5.8.8] > > [...] > > Do you want to install perl as /usr/bin/perl? [n] > > [...] > > I can use the #! construct to start perl on your system. This will > make startup of perl scripts faster, but may cause problems if you > want to share those scripts and perl is not in a standard place > (/opt/perl/5.8.8/bin/perl) on all your platforms. The alternative is to > force > a shell by starting the script with a single ':' character. > > What shall I put after the #! to start up perl ("none" to not use #!)? > [/opt/perl/5.8.8/bin/perl] > > (Which I always change to /usr/bin/perl.) > > Allison > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > That's the $Config{perlpath} var, btw. Very useful to reference if you're doing script generation, like Catalyst's startup scripts, etc. We generate our scripts with: $self->{startperl} = "#!$Config{perlpath} -w"; -J From scratchcomputing at gmail.com Wed Aug 27 16:05:52 2008 From: scratchcomputing at gmail.com (Seven till Seven) Date: Wed, 27 Aug 2008 16:05:52 -0700 Subject: [Pdx-pm] meeting in 2 week: Scientific Computing with Math::GSL Message-ID: <200808271605.53001.ewilhelm@cpan.org> Wed. September 10th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Speaker: Jonathan Leto Topic: Scientific Computing with Math::GSL This talk will be an introduction to doing scientific computing with Perl and Math::GSL. -- http://pdx.pm.org From keithl at kl-ic.com Thu Aug 28 16:39:59 2008 From: keithl at kl-ic.com (Keith Lofstrom) Date: Thu, 28 Aug 2008 16:39:59 -0700 Subject: [Pdx-pm] Suggested Perl Best *Operating* Practices? Message-ID: <20080828233935.GA26347@gate.kl-ic.com> I learned many things from the recent flurry of excellent responses to my postings about Red Hat and Perl. One of the things that I learned (again) is that there are many useful Perl administration and configuration techniques known by the cognoscenti that do not appear to be collected anywhere. Since the Web Knows Everything, that may be my inability to search. Perhaps the Perl cognoscenti (or a reasonable facsimile thereof) can point me at a book, article, or website that is a complete guide to setting up and maintaining a Perl environment. I ordered the book "Perl for System Administration" (O'R 2000), hoping for some clues when it arrives. It may just add to the dozens of Perl books gracing my shelves, containing many programming gems but lacking deployment details. I suspect that the book I really want will be titled something like "Administering Perl". This imaginary book will include details like security maintenance of multiple Perls, backing out of bad modules, finding the best stuff on CPAN, local modification best practices, etc. It would be a fat book full of contradictory advice, because, after all, TIMTOWTDI. Or it might suggest which technique to use in which circumstance, and the level of Perl expertise (available at popular prices, consult your local pm.org) needed to accomplish various sizes of task. I appreciate Perl, and the people that devote large parts of their lives to it. But most of us have other missions to accomplish, and haven't the time to reach that level of expertise. Some guidelines about properly using the bounty (code and consultants) created by our mongering sistren and brethren might help expand that usage. Keith -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From scratchcomputing at gmail.com Thu Aug 28 17:31:51 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Thu, 28 Aug 2008 17:31:51 -0700 Subject: [Pdx-pm] Suggested Perl Best *Operating* Practices? In-Reply-To: <20080828233935.GA26347@gate.kl-ic.com> References: <20080828233935.GA26347@gate.kl-ic.com> Message-ID: <200808281731.51515.ewilhelm@cpan.org> # from Keith Lofstrom # on Thursday 28 August 2008 16:39: >I suspect that the book I really want will be titled something like >"Administering Perl". ?This imaginary book will include ... And may or may not be out of date by the time it gets to print. >But most of us have other missions to accomplish, and >haven't the time to reach that level of expertise. Perhaps those who deal extensively with deployment, installation, smoke testing, and etc tend to roll their own tools (or build distro packages) rather than documenting how to do it in the general or cross-platform case? The .packlist thing is a good example -- you can use it to delete the package contents, but not to check whether you're breaking a dependency while doing so. Or someone (with a bigger stack of tuits than I) could cleanup PAUSE, CPAN(PLUS).pm, Module::Build, configure, and the rest of the process to the point that you don't need a book full of knowledge about historical accidents and a system audit to install Perl and a couple of modules? "More than one way to do it" is like "A certain way to do it on Tuesday in Reno if it's raining (in Plano) and your name has an h in it". --Eric -- "...our schools have been scientifically designed to prevent overeducation from happening." --William Troy Harris --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From chromatic at wgz.org Thu Aug 28 17:55:35 2008 From: chromatic at wgz.org (chromatic) Date: Thu, 28 Aug 2008 17:55:35 -0700 Subject: [Pdx-pm] Suggested Perl Best *Operating* Practices? In-Reply-To: <200808281731.51515.ewilhelm@cpan.org> References: <20080828233935.GA26347@gate.kl-ic.com> <200808281731.51515.ewilhelm@cpan.org> Message-ID: <200808281755.35869.chromatic@wgz.org> On Thursday 28 August 2008 17:31:51 Eric Wilhelm wrote: > Or someone (with a bigger stack of tuits than I) could cleanup PAUSE, > CPAN(PLUS).pm, Module::Build, configure, and the rest of the process to > the point that you don't need a book full of knowledge about historical > accidents and a system audit to install Perl and a couple of modules? > "More than one way to do it" is like "A certain way to do it on Tuesday > in Reno if it's raining (in Plano) and your name has an h in it". Fixing a bunch of old and crufty hacks that aren't Perl is very much the Perl way. Fixing a bunch of slightly less old but no less crufty hacks which are Perl is, sadly, not the Perl way. Having failed to refactor File::Find for seven years or even patch broken code out of the documentation of certain core modules, -- c From dex.pdx at gmail.com Fri Aug 29 12:32:09 2008 From: dex.pdx at gmail.com (Dex) Date: Fri, 29 Aug 2008 12:32:09 -0700 Subject: [Pdx-pm] Suggested Perl Best *Operating* Practices? In-Reply-To: References: Message-ID: <1220038329.6716.33.camel@ofelia> Were you the one who posted that thing on Slashdot about the slow perl bug with CentOS (RHEL) 5? Either way, I posted a bit on there about how Perl programmers should package their deployments with RPM and Yum when on CentOS to allow for external system dependencies (like a custom built Perl). On Fri, 2008-08-29 at 12:00 -0700, pdx-pm-list-request at pm.org wrote: > [Pdx-pm] Suggested Perl Best *Operating* Practices? From scratchcomputing at gmail.com Sat Aug 30 01:06:18 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sat, 30 Aug 2008 01:06:18 -0700 Subject: [Pdx-pm] Linux::USBKeyboard - press button for bacon Message-ID: <200808300106.19057.ewilhelm@cpan.org> For those who missed the last meeting, or were just waiting for it to be on CPAN. http://scratchcomputing.com/svn/Linux-USBKeyboard/tags/0.02/examples/echo_bacon.pl --Eric -- "Time flies like an arrow, but fruit flies like a banana." --Groucho Marx --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From scratchcomputing at gmail.com Sun Aug 31 22:53:11 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sun, 31 Aug 2008 22:53:11 -0700 Subject: [Pdx-pm] Perl header file headache In-Reply-To: <9aaadf9c0808231056w16e4f835kf28fe7f80e83a689@mail.gmail.com> References: <9aaadf9c0808231056w16e4f835kf28fe7f80e83a689@mail.gmail.com> Message-ID: <200808312253.11510.ewilhelm@cpan.org> # from Jonathan Leto # on Saturday 23 August 2008 10:56: >gcc -I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -c -shared >-fpic -I/usr/local/include -Wno-strict-aliasing -Wno-unused-function >-Wno-unused-value -Wno-unused-function -Wno-unused-variable -o Ow. Your Build.PL has a bunch of hacked-up Module::Build guts in it, so you're not getting the right arguments to the linker. I don't know where you got this Build.PL stuff, but you should send it back for a refund and tell them to report bugs in RT if that is the reason this is like this. --Eric -- "...our schools have been scientifically designed to prevent overeducation from happening." --William Troy Harris --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------