As I understand it, Debian's freezes, like most software freezes I'm aware of, are 'except for bug fix' freezes. If that is correct, then the period right before the freeze is actually the *least* stable, not the most stable.
Also, I've heard that patches similar to the one that caused the recent SSL heartaches are fairly endemic: patches which do not solve any technical problems. Instead, these patches things like eliminate warnings in a manner that the upstream maintainer is unwilling to do. (It is one thing to take the time to eliminate warnings when the upstream maintainer does not want to spend the time. It's quite another matter to eliminate warnings in a manner that the upstream maintainer is not willing to then apply to the main trunk.) If that is, in fact the case, it doesn't surprise me at all that their binary Embperl package doesn't work completely correctly. Ed On Tue, 15 Jul 2008, Neil Gunton wrote: > Hi Andrew, > > There definitely seems to be some kind of problem with the current > binary Embperl package included with Lenny. All I did was build > Embperl from the Debian source (using the standard build procedure, > rather than the "debian way") and everything "just worked". No changes > to the config. Very strange! Oh well, at least it works now, which is > a relief. > > What is your experience of Lenny's stability with respect to software > updates? I hear they are entering a freeze soon. On the one hand, I > would think that must mean that it must be pretty stable, but on the > other hand someone commented that you sometimes see a flurry of > hurried (and sometimes unwise) updates checked in to beat the freeze. > Are you running it on a production server? Currently, I'm planning on > installing Lenny on my server this Wednesday, just biting the bullet > and upgrading everything. I've been running Apache 1.3, mod_perl 1 and > Embperl 1.3 for the last eight years or so, but when I tried > installing that on Lenny it seemed to break - maybe perl 5.10 or > something. This is what made me consider the sweeping upgrade... > should be easier to just live in the apt-get world, too. > > With my old apache setup, I had two builds (on the same machine) > working as a back-end mod_perl, and a front-end lightweight reverse > proxy. I'm wondering if I'll need to do that with Apache 2.2; it seems > that it has caching built in, so maybe no need to proxy for > performance. The idea was that I could run a lot more of the caching > reverse proxy instances (since they use much less memory) and so with > caching this allowed me to withstand several slashdottings without > breaking a sweat. But if everything is coming through the mod_perl > apache, then I won't be able to run as many instances. I don't know > how that will affect performance yet, it should be interesting. > > Neil > > Andrew O'Brien wrote: >> Hi Neil, >> >> We use debian lenny and for a while we were running locally compiled >> versions of 2.2.0 with this patch applied: >> http://www2.ecos.de/~mailarc/embperl/2007-07/msg00016.html. I can't >> recall any problems with the package rebuild process. It was >> basically: >> >> a) apt-get source libembperl-perl >> b) apt-get build-dep libembperl-perl >> c) dpkg -x *dsc >> d) cd libembperl-perl-2.2.0 >> e) apply local patches >> f) optionally create new entry in ./debian/changelog to update the >> version number >> g) ./debian/rules binary >> h) dpkg -i ../filename.deb >> >> That said, since later versions (currently running stock 2.2.0-3.1) >> this hasn't been necessary so I'm just running stock >> apache2/mod_perl/embperl: >> >> dpkg -l libembperl-perl apache2-mpm-prefork libapache2-mod-perl2 >> >> ||/ Name Version Description >> +++-==============-==============-====================================== >> ====== >> ii apache2-mpm-pr 2.2.8-4 Traditional model for Apache HTTPD >> ii libapache2-mod 2.0.4-1 Integration of perl with the Apache2 >> web ser >> ii libembperl-per 2.2.0-3.1 A system for building dynamic websites >> with >> >> >> I don't recall ever having to do anything too special on the config >> side. Here are the relevant snippets. Note that some of these might >> be the defaults as I just tweaked a 1.3.6 install just like you're >> doing: >> >> 1. /etc/apache2/mods-available/zembperl.* left as stock >> >> 2. /etc/apache2/startup.pl (cut down version) -------------------------- >> >> use strict; >> use Apache2::ServerUtil; >> >> BEGIN { >> # compile-time sanity check >> $ENV{MOD_PERL} or die "not running under mod_perl!"; >> } >> >> # We want to do this only when the sever restarts. (The start process >> # includes a restart). The below variable has a value of 1 during >> # server start/stop and a value greater than one during the second >> # phase of server starting and any graceful restart. >> >> if ( Apache2::ServerUtil::restart_count() > 1 ) { >> # make Apache warn with more information >> use Carp (); >> #$SIG{__WARN__} = \&Carp::cluck; >> $SIG{'USR2'} = sub { Carp::confess("Caught SIGUSR2!"); }; >> >> # limit resource usage of apache2 children. We exit cleanly if we >> # have pass a given maximum unshared (ie not copy-on-write) memory >> # size. This relies on having /proc/self/smaps which is in recent >> # 2.6 kernels >> # >> # This requires the following in the httpd.conf: >> # PerlCleanupHandler Apache2::SizeLimit >> # >> # Note: This does NOT impose a hard system limit! See >> # Apache2::Resource for rlimit stuff >> use Apache2::SizeLimit; >> #$Apache2::SizeLimit::MAX_PROCESS_SIZE = 80000; # 80 MiB >> #$Apache2::SizeLimit::MIN_SHARED_SIZE = 5000; # 5 MiB >> $Apache2::SizeLimit::MAX_UNSHARED_SIZE = 300000; # 300 MiB >> $Apache2::SizeLimit::CHECK_EVERY_N_REQUESTS = 2; >> >> # Your request base class, if any >> use Your::Optional::RequestClass; >> >> # Embperl modules >> use Embperl (); >> use Embperl::Object (); >> >> # Everything site-specific here >> } >> 1; >> >> >> 3. /etc/apache2/sites-available/yoursite --------------------------- >> >> PerlRequire startup.pl >> PerlCleanupHandler Apache2::SizeLimit >> <VirtualHost *:80> >> # Usual Server* and log directives >> DocumentRoot /blah >> >> # You can ignore these. I just show a nice error page if there >> # is actually an embperl/perl error >> ErrorDocument 500 /error/index.html >> >> # Embperl directives >> EMBPERL_APPNAME your_application_name_here >> # optReturnError(262144) for ErrorDocument above >> EMBPERL_OPTIONS 262144 >> EMBPERL_DEBUG 0 >> # Same as old optRawInput >> EMBPERL_INPUT_ESCMODE 0 >> EMBPERL_OBJECT_BASE base.epl >> EMBPERL_OBJECT_STOPDIR "/var/www/yoursite/webroot" >> EMBPERL_OBJECT_HANDLER_CLASS Your::Optional::RequestClass >> EMBPERL_URIMATCH "\.(html|epl)$" >> EMBPERL_OBJECT_ADDPATH "/var/www/yoursite/webroot/share" >> EMBPERL_COOKIE_PATH / >> EMBPERL_COOKIE_EXPIRES +3M >> EMBPERL_MAIL_ERRORS_TO "[EMAIL PROTECTED]" >> >> # Other site-specific directives here >> >> # Block direct access to .epl files as all publically >> # accessible embperl pages are .html >> <Files *.epl> >> Order deny,allow >> Deny from all >> </Files> >> </VirtualHost> >> >> Hope this helped. >> >> - Andrew >> >>> -----Original Message----- >>> From: Neil Gunton [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, 15 July 2008 7:15 AM >>> To: embperl@perl.apache.org >>> Subject: Re: Problem using Embperl on Debian Lenny >>> >>> Success! >>> >>> I finally tried this: >>> >>> 1. Install the Debian source for mod_perl and apache2.2 (previously >>> I had tried building against the non-debian source tarballs) >>> 2. Install Debian source for Embperl from Lenny >>> 3. Build Embperl *not* using the "debian way", but rather the usual: >>> perl Makefile.PL (it found the correct Debian apache sources) >>> make >>> make test >>> make install >>> >>> Now, for some strange reason, it works - even though the binary >>> version of this should really be the same, am I right??? Something >>> must have gotten out of sync maybe at the object file level, which >>> was corrected by the rebuild. >>> >>> Note that I couldn't make this work by building tarball Embperl >>> against tarball apache, or tarball Embperl against debian apache, or >>> by using "the debian way" to build the Embperl source against the >>> Debian apache... it only worked by building the Debian Embperl >>> against the Debian apache, using the *traditional* build method. I >>> was stunned when I started up apache and my test page now "just >>> works". >>> >>> This might be useful for anybody else who is trying to use Embperl >>> 2.2 with Apache 2.2 and mod_perl2 on the current Debian Lenny - >>> those binary packages seem to be broken and need to be fixed. >>> Building as above from source (note - NOT the debian build) seems to >>> make it work. >>> >>> Wow, I carried on a whole conversation with myself on a mailing >>> list. Not as lonely as I thought it might be... is there *anybody* >>> else here, or has Embperl died the slow death with developers? >>> >>> Neil >>> >>> Neil Gunton wrote: >>>> Ok, I tried building the Debian Embperl 2.2.0 that comes with Lenny >>>> from source. I am not experienced at this. After some poking >>>> around, I turned up this page on building packages: >>>> >>>> http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html >>>> >>>> After cd'ing into the libembperl-perl-2.2.0 directory, I did this: >>>> >>>> apt-get build-dep libembperl-perl-2.2.0 >>>> >>>> This initially gave some errors, but I tried doing apt-get install >>>> on the stuff it seemed to be complaining about, and retried until >>>> it gave no errors. So far so good. Next I tried building, again in >>>> the embperl source dir: >>>> >>>> debuild -us -uc >>>> >>>> This did a lot of compiling and testing, and seemed to be >>>> successful, but eventually stopped with the following errors: >>>> >>>> ... >>>> Manifying blib/man3/Embperl::Object.3pm >>>> Manifying blib/man3/Embperl::Features.3pm >>>> Manifying blib/man3/Embperl::Syntax::POD.3pm >>>> Manifying blib/man3/Embperl::TipsAndTricks.3pm >>>> Manifying blib/man3/Embperl::Form::Control::checkbox.3pm >>>> Files found in blib/arch: installing files in blib/lib into >>>> architecture dependent library tree >>>> Writing /usr/lib/perl5/auto/Embperl/.packlist >>>> Appending installation info to /usr/lib/perl/5.10/perllocal.pod >>>> make[1]: Leaving directory `/root/libembperl-perl-2.2.0' >>>> install -m 755 *cgi.pl debian/libembperl-perl/usr/lib/cgi-bin/ >>>> mv debian/libembperl-perl/usr/share/man/man3/*[a-z]D.3pm >>>> debian/libembperl-perl/usr/share/man/de/man3/*[a-z].3pm >>>> mv: cannot stat >>>> `debian/libembperl-perl/usr/share/man/man3/*[a-z]D.3pm': >>>> No such file or directory >>>> make: *** [install] Error 1 >>>> dpkg-buildpackage: failure: fakeroot debian/rules binary >>>> gave error exit status 2 >>>> debuild: fatal error at line 1319: >>>> dpkg-buildpackage -rfakeroot -D -us -uc failed >>>> >>>> So am I building this wrong? I have fakeroot installed. >>>> >>>> I still don't know if this has anything to do with my original >>>> problem or not. The fact that the mod_perl tests all seemed to >>>> complete ok gives me some hope, but I still wonder if there isn't >>>> some very small API inconsistency that has crept in somewhere, >>>> which is making Embperl barf in the Apache2 environment. Again, any >>>> clues would be much appreciated. >>>> Thanks! >>>> >>>> Neil >>>> >>>> Neil Gunton wrote: >>>>> Can anybody please lend any insights here (see below)? Is anybody >>>>> actually using the stock Embperl2 that comes with Debian Lenny >>>>> (testing), along with stock Apache2 and mod_perl2? Are there >>>>> problems with it, or am I just doing something stupid with my >>>>> configuration? The error seems to imply that there may be >>>>> something out of sync between Embperl and the Apache2.2 API, but >>>>> it could also just be a symptom of something I'm doing wrong. >>>>> Right now I am out of ideas. >>>>> >>>>> I don't mean to be pushy, but I am going up to my datacenter in >>>>> Chicago on Wednesday (round trip takes all day) to rebuild my >>>>> server. I'd like to find out as soon as possible before then >>>>> whether it's going to be possible to install Debian Lenny, with >>>>> all its latest software, or if I'll instead have to stay with >>>>> Etch. I'd much rather go to Lenny, but if there are intrinsic >>>>> problems with the Debian packages of Embperl then I'll have to >>>>> rethink. >>>>> >>>>> Any help would be *much* appreciated... >>>>> >>>>> Thanks! >>>>> >>>>> Neil >>>>> >>>>> Neil Gunton wrote: >>>>>> Hi, I've been using Embperl 1.3 for years now on Apache 1.3, and >>>>>> now I'm finally trying to upgrade my websites to use the latest >>>>>> Embperl which is included with Debian Lenny (testing). So that >>>>>> means Apache 2.2, mod_perl 2, Embperl 2.2... I am just >>>>>> installing all this from the deb packages, not from source. >>>>>> >>>>>> I'm having a problem getting Embperl 2.2.0 to run. I have a very >>>>>> simple config set up in >>>>>> /etc/apache2/mods-available/zembperl.conf: >>>>>> >>>>>> PerlModule Embperl >>>>>> EMBPERL_OBJECT_BASE base.epl >>>>>> <FilesMatch ".*\.html$"> >>>>>> SetHandler perl-script >>>>>> PerlHandler Embperl::Object >>>>>> Options ExecCGI >>>>>> </FilesMatch> >>>>>> >>>>>> The zembperl.load is left unchanged. >>>>>> >>>>>> In /etc/apache2/sites-available/dev.neilgunton.com I have: >>>>>> NameVirtualHost dev.neilgunton.com >>>>>> <VirtualHost dev.neilgunton.com> >>>>>> ServerName dev.neilgunton.com >>>>>> ServerAlias *.dev.neilgunton.com >>>>>> DocumentRoot /www-dev/vhosts/test >>>>>> PerlSetEnv EMBPERL_APPNAME neilgunton_dev >>>>>> </VirtualHost> >>>>>> >>>>>> When I try to access dev.neilgunton.com, I get 500 error, with >>>>>> this in the log: >>>>>> >>>>>> ERR: 24: Error in Perl code: Can't call method "component" on >>>>>> an undefined value at /usr/lib/perl5/Embperl/App.pm line 58.\n >>>>>> ERR: 61: : Unknown recipe 'Embperl' >>>>>> Can't call method "log_file_start_pos" on an undefined value at >>>>>> /usr/lib/perl5/Embperl/App.pm line 81. >>>>>> >>>>>> Any clues on what I'm doing wrong here? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
