Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: Dev

[RELEASE CANDIDATE]: mod_perl-2.0.6 RC2

 

 

ModPerl dev RSS feed   Index | Next | Previous | View Threaded


torsten.foertsch at gmx

Feb 18, 2012, 11:25 AM

Post #1 of 12 (977 views)
Permalink
[RELEASE CANDIDATE]: mod_perl-2.0.6 RC2

Hi,

I am starting a new thread here because a) this is about RC2 not RC1 and b)
the RC1 thread is already too long for me to cope with.

To summarize the current state as I see it. We have a RC2 at

http://people.apache.org/~phred/mod_perl-2.0.6-rc2.tar.gz

It got 2 +1 for linux (me) and osx (fred).

On windows Steve reported another problem with recursive "make" invocations.
He also sent a patch to the list but didn't commit it for some reason. If I
understood the patch correctly the problem are the hard-wired "make" options
(-k and -C). So, I committed a slightly different patch (more makeish I
think).

Steve, could you please confirm that revision 1245946 works for you?

I have also just committed revision 1290839 to have our top-level Makefile.PL
pass on MP_APXS and MP_AP_PREFIX as environment variables. At least this patch
doesn't disturb anything here. But I doubt that it solves Steve's Apache-
Reload problem.

The A::R Makefile.PL reads:

...
if ($ENV{MOD_PERL_2_BUILD}) {
push @ARGV, "-apxs $ENV{MP_APXS}";
my $mp_gen = satisfy_mp_generation(2);
}
...

So the string "-apxs ..." is pushed to @ARGV as a single argument. I think
that should rather read

push @ARGV, "-apxs", $ENV{MP_APXS};

Steve, if you want to play with it remember to change the place where the
additional parameter is removed from @ARGV later, as well. Around line 50 it
reads:

if ($ENV{MOD_PERL_2_BUILD}) {
pop @ARGV; # that should now be 2 times pop or a splice
}

These lines of code are also present in A::SL and have their origin there.
They appeared in revision 441414.

Hopefully RC3 will then get 3 +1. I'd really like to get it over with before
my vacation starting mid-next week but hope is weak.


$ svn diff -c 1245946
Index: Makefile.PL
===================================================================
--- Makefile.PL (revision 1245945)
+++ Makefile.PL (revision 1245946)
@@ -789,24 +789,23 @@
$(PASSENV) \
$(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \
t/TEST -bugreport -verbose=$(TEST_VERBOSE) $(TEST_FILES)
- $(MAKE) -k run_subtests

run_subtests ::
- $(MAKE) -C ModPerl-Registry test
+ cd ModPerl-Registry && $(MAKE) test

run_subtests ::
- $(MAKE) -C Apache-Reload test
+ cd Apache-Reload && $(MAKE) test

EOF

$preamble .= <<'EOF' unless $build->mpm_is_threaded();
run_subtests ::
- $(MAKE) -C Apache-SizeLimit test
+ cd Apache-SizeLimit && $(MAKE) test

EOF

$preamble .= <<'EOF';
-test :: pure_all run_tests test_clean
+test :: pure_all run_tests run_subtests
EOF

return $preamble;


Another funny discovery I made in our top-level Makefile.PL. There is a
function named win32_fetch_apxs which is called almost first thing if we run
on WIN32. It looks for a win32_fetch_apxs executable. I found such a script in
build/. It tries to fetch the archive http://perl.apache.org/dist/win32-
bin/apxs_win32.tar.gz via LWP. The newest files in this directory from
2007-04-18 03:32. Do we really need this?

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 18, 2012, 4:03 PM

Post #2 of 12 (963 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

[.Replying with the Outlook QuoteFix macro installed at last :-) ...]

Torsten Förtsch wrote on 2012-02-18:
> Hi,
>
> I am starting a new thread here because a) this is about RC2 not RC1
> and b) the RC1 thread is already too long for me to cope with.
>
> To summarize the current state as I see it. We have a RC2 at
>
> http://people.apache.org/~phred/mod_perl-2.0.6-rc2.tar.gz
> It got 2 +1 for linux (me) and osx (fred).
>
> On windows Steve reported another problem with recursive "make"
> invocations. He also sent a patch to the list but didn't commit it for
> some reason. If I understood the patch correctly the problem are the
> hard-wired "make" options (-k and -C). So, I committed a slightly
> different patch (more makeish I think).
>
> Steve, could you please confirm that revision 1245946 works for you?
>

I didn't commit because we're in the middle of making a release so I thought it wouldn't be appropriate without the RM's approval. Anyway, I like your patch better, and I can confirm that it works for me :-)


> I have also just committed revision 1290839 to have our top-level
> Makefile.PL pass on MP_APXS and MP_AP_PREFIX as environment variables.
> At least this patch doesn't disturb anything here. But I doubt that it
> solves Steve's Apache- Reload problem.

Indeed it doesn't solve my problem. As I wrote before, even setting the MP_APXS environment variable myself before running Makefile.PL didn't help.


>
> The A::R Makefile.PL reads:
>
> ...
> if ($ENV{MOD_PERL_2_BUILD}) {
> push @ARGV, "-apxs $ENV{MP_APXS}";
> my $mp_gen = satisfy_mp_generation(2);
> }
> ...
>
> So the string "-apxs ..." is pushed to @ARGV as a single argument. I
> think that should rather read
>
> push @ARGV, "-apxs", $ENV{MP_APXS};

Yes, and hence we do indeed need to pass MP_APXS through in the environment, as you've now done in revision 1290839, plus I need to run "perl Makefile.PL MP_APXS=..." now (as per the INSTALL file!), rather than "perl Makefile.PL MP_AP_PREFIX=..." (as I've always done). I'm ok with that, but see later:


> Steve, if you want to play with it remember to change the place where
> the additional parameter is removed from @ARGV later, as well. Around
> line 50 it
> reads:
>
> if ($ENV{MOD_PERL_2_BUILD}) {
> pop @ARGV; # that should now be 2 times pop or a
> splice
> }
> These lines of code are also present in A::SL and have their origin
> there. They appeared in revision 441414.

Pushing two args onto @ARGV as you suggest works for me, but splicing them off again (splice @ARGV, -2) doesn't! It gives the error "Modification of non-creatable array value attempted", due to check_for_apache_test() calling Apache::TestMM::filter_args(), which actually assigns a new value to @ARGV (in my case, an empty array!). Given that @ARGV is getting rewritten anyway, I think it is simplest to not worry about trying pop the pushed values off again, so the attached patch simply deletes the pop lines.


>
> Hopefully RC3 will then get 3 +1. I'd really like to get it over with
> before my vacation starting mid-next week but hope is weak.
>
>
> $ svn diff -c 1245946 Index: Makefile.PL
> =================================================================== ---
> Makefile.PL (revision 1245945) +++ Makefile.PL (revision 1245946) @@
> -789,24 +789,23 @@
> $(PASSENV) \
> $(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \
> t/TEST -bugreport -verbose=$(TEST_VERBOSE) $(TEST_FILES)
> - $(MAKE) -k run_subtests
>
> run_subtests ::
> - $(MAKE) -C ModPerl-Registry test
> + cd ModPerl-Registry && $(MAKE) test
>
> run_subtests ::
> - $(MAKE) -C Apache-Reload test
> + cd Apache-Reload && $(MAKE) test
>
> EOF
> $preamble .= <<'EOF' unless $build->mpm_is_threaded();
> run_subtests ::
> - $(MAKE) -C Apache-SizeLimit test
> + cd Apache-SizeLimit && $(MAKE) test
>
> EOF
> $preamble .= <<'EOF';
> -test :: pure_all run_tests test_clean
> +test :: pure_all run_tests run_subtests
> EOF
> return $preamble;
>
> Another funny discovery I made in our top-level Makefile.PL. There is a
> function named win32_fetch_apxs which is called almost first thing if we
> run on WIN32. It looks for a win32_fetch_apxs executable. I found such a
> script in build/. It tries to fetch the archive
> http://perl.apache.org/dist/win32- bin/apxs_win32.tar.gz via LWP. The
> newest files in this directory from 2007-04-18 03:32. Do we really need
> this?

I didn't realize that the top-level Makefile.PL actually fetches apxs for you if you don't have it, but it seems worth leaving in if I understand things correctly:

My understanding is that apxs is required for building modules likes mod_perl and libapreq and that it normally gets installed with Apache httpd but doesn't get installed on Win32, hence the existence of that separate apxs_win32.tar.gz package. It was created by the sadly departed Randy Kobes, and has not been updated since but currently still works.

I've always installed it manually first, and then built mod_perl, but it looks like the mod_perl build will fetch it if it's missing, installing it into the MP_AP_PREFIX location (if given on the command-line). Having said that, the build currently doesn't work correctly on Win32 if you only specify MP_AP_PREFIX as I've done up until now: we now need MP_APXS to be specified too. Therefore, the attached patch also modifies the fetch function to set $build->{MP_APXS}, akin to what prompt_for_apxs() does.

I'm curious how the build *does* work on other platforms, though: why has nobody else hit the same problem with Apache-Reload's tests not getting run? Is everyone else using MP_APXS rather than MP_AP_PREFIX anyway? If so then should be drop the MP_AP_PREFIX argument?

(I again haven't applied my patch myself because I'm not sure how to go about patching Reload and SizeLimit. I see they're downloaded into my mod_perl working copy as "externals", but can I commit changes from there? Also, the version of Reload in that working copy seems to be newer than what's in our RC2. Is that intentional? My working copy of mod_perl (Trunk) contains Reload 0.12-dev, with a changes file saying that the last thing added to 0.11 was an Apache-Test 1.34 dependency, but RC2 contains what purports to be 0.11 and yet it doesn't contain that Apache-Test 1.34 dependency...)
Attachments: apxs.patch (2.19 KB)


torsten.foertsch at gmx

Feb 19, 2012, 10:25 AM

Post #3 of 12 (950 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

On Sunday, 19 February 2012 00:03:56 Steve Hay wrote:
> > Steve, could you please confirm that revision 1245946 works for you?
>
> I didn't commit because we're in the middle of making a release so I thought
> it wouldn't be appropriate without the RM's approval. Anyway, I like your
> patch better, and I can confirm that it works for me

Fine. So, I think the modperl side is now in proper shape.

> > The A::R Makefile.PL reads:
> > ...
> >
> > if ($ENV{MOD_PERL_2_BUILD}) {
> > push @ARGV, "-apxs $ENV{MP_APXS}";
> > my $mp_gen = satisfy_mp_generation(2);
> > }
> >
> > ...
> > So the string "-apxs ..." is pushed to @ARGV as a single argument. I
> > think that should rather read
> >
> >
> > push @ARGV, "-apxs", $ENV{MP_APXS};
>
> Yes, and hence we do indeed need to pass MP_APXS through in the environment,
> as you've now done in revision 1290839, plus I need to run "perl Makefile.PL
> MP_APXS=..." now (as per the INSTALL file!), rather than "perl Makefile.PL
> MP_AP_PREFIX=..." (as I've always done). I'm ok with that, but see later:

> Pushing two args onto @ARGV as you suggest works for me, but splicing them
> off again (splice @ARGV, -2) doesn't! It gives the error "Modification of
> non-creatable array value attempted", due to check_for_apache_test()
> calling Apache::TestMM::filter_args(), which actually assigns a new value
> to @ARGV (in my case, an empty array!). Given that @ARGV is getting
> rewritten anyway, I think it is simplest to not worry about trying pop the
> pushed values off again, so the attached patch simply deletes the pop
> lines.

Your patch looks fine to me.

How to proceed from here is a question we'd have to ask Fred. I see 3 options:

1) push out RC2 as is as 2.0.6

that would make Steve unhappy and we need another +1 in any case. The
reasoning for this solution is that the bug in A::R and A::SL sits there for
years and has survived several public releases. Two thirds of all of the SVN
commits came in after the one that introduced the bug.

2) commit Steve's changes to A::R and A::SL and roll another RC with them

Since these changes affect only the way modperl communicates MP_APXS to
bundled submodules at build time and nothing else one could argue to avoid the
overhead of creating 2 new releases and bundle the patched versions.

This is the option I'd prefer.

3) go the full circle: new releases of A::R and A::SL, then another modperl-RC


Further, it seems to me that MP_AP_PREFIX, MP_AP_DESTDIR, MP_APR_CONFIG and
MP_APR_LIB are all historical cruft and should be removed. Why do we need
dozens of ways to build modperl. The apxs command should know all the answers
of how to build and where to install modperl.

> > Another funny discovery I made in our top-level Makefile.PL. There is a
> > function named win32_fetch_apxs ...
>
> I didn't realize that the top-level Makefile.PL actually fetches apxs for
> you if you don't have it, but it seems worth leaving in if I understand
> things correctly:
>
> My understanding is that apxs is required for building modules likes
> mod_perl and libapreq and that it normally gets installed with Apache httpd
> but doesn't get installed on Win32, hence the existence of that separate
> apxs_win32.tar.gz package.

Yes, apxs is needed to answer questions like "Which C-compiler should be used
and which options it should be passed?" or "Where is the httpd binary
installed and where do modules go to?" or "Which httpd include files should be
used?" apxs can actually do a bit more. But such are the questions we ask it.
To answer them apxs here refers to a file share/build/config_vars.mk installed
with httpd. The absolute path of that file is hard-wired in apxs. So, apxs is
tightly bound to the httpd modperl is built for.

So, we have 2 options. We could either update the stuff at
http://perl.apache.org/dist/win32-bin and provide a working modern combination
of perl, httpd and modperl for win32 (and perhaps 64bit).

Or we could drop the stuff. Keeping it as is is a bit embarrassing, I feel.

> (I again haven't applied my patch myself because I'm not sure how to go
> about patching Reload and SizeLimit. I see they're downloaded into my
> mod_perl working copy as "externals", but can I commit changes from there?

I think you can

cd Apache-Reload && svn ci ...

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 19, 2012, 10:31 AM

Post #4 of 12 (950 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

2012/2/19 Torsten Förtsch <torsten.foertsch [at] gmx>:
> 2) commit Steve's changes to A::R and A::SL and roll another RC with them
>
> Since these changes affect only the way modperl communicates MP_APXS to
> bundled submodules at build time and nothing else one could argue to avoid the
> overhead of creating 2 new releases and bundle the patched versions.
>
> This is the option I'd prefer.

I prefer this also. I'm not sure how to reconcile this in the Changes
file for both modules though. We could add them to the tagged versions
in svn and update the Changes file there, but then the exact files
shipped with mod_perl and what is on CPAN won't match up for
Makefile.PL. I could see this as being viewed as a bad practice, but
since the change is to the Makefile.PL only, I think breaking the
rules in this instance only is the pragmatic approach.

>
> 3) go the full circle: new releases of A::R and A::SL, then another modperl-RC
>
>
> Further, it seems to me that MP_AP_PREFIX, MP_AP_DESTDIR, MP_APR_CONFIG and
> MP_APR_LIB are all historical cruft and should be removed. Why do we need
> dozens of ways to build modperl. The apxs command should know all the answers
> of how to build and where to install modperl.
>
>> > Another funny discovery I made in our top-level Makefile.PL. There is a
>> > function named win32_fetch_apxs ...
>>
>> I didn't realize that the top-level Makefile.PL actually fetches apxs for
>> you if you don't have it, but it seems worth leaving in if I understand
>> things correctly:
>>
>> My understanding is that apxs is required for building modules likes
>> mod_perl and libapreq and that it normally gets installed with Apache httpd
>> but doesn't get installed on Win32, hence the existence of that separate
>> apxs_win32.tar.gz package.
>
> Yes, apxs is needed to answer questions like "Which C-compiler should be used
> and which options it should be passed?" or "Where is the httpd binary
> installed and where do modules go to?" or "Which httpd include files should be
> used?" apxs can actually do a bit more. But such are the questions we ask it.
> To answer them apxs here refers to a file share/build/config_vars.mk installed
> with httpd. The absolute path of that file is hard-wired in apxs. So, apxs is
> tightly bound to the httpd modperl is built for.
>
> So, we have 2 options. We could either update the stuff at
> http://perl.apache.org/dist/win32-bin and provide a working modern combination
> of perl, httpd and modperl for win32 (and perhaps 64bit).
>
> Or we could drop the stuff. Keeping it as is is a bit embarrassing, I feel.
>
>> (I again haven't applied my patch myself because I'm not sure how to go
>> about patching Reload and SizeLimit. I see they're downloaded into my
>> mod_perl working copy as "externals", but can I commit changes from there?
>
> I think you can
>
>  cd Apache-Reload && svn ci ...
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 19, 2012, 10:34 AM

Post #5 of 12 (950 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

2012/2/19 Fred Moyer <fred [at] redhotpenguin>:
> 2012/2/19 Torsten Förtsch <torsten.foertsch [at] gmx>:
>> 2) commit Steve's changes to A::R and A::SL and roll another RC with them
>>
>> Since these changes affect only the way modperl communicates MP_APXS to
>> bundled submodules at build time and nothing else one could argue to avoid the
>> overhead of creating 2 new releases and bundle the patched versions.
>>
>> This is the option I'd prefer.
>
> I prefer this also.  I'm not sure how to reconcile this in the Changes
> file for both modules though. We could add them to the tagged versions
> in svn and update the Changes file there, but then the exact files
> shipped with mod_perl and what is on CPAN won't match up for
> Makefile.PL.  I could see this as being viewed as a bad practice, but
> since the change is to the Makefile.PL only, I think breaking the
> rules in this instance only is the pragmatic approach.

Adding a +1 to this plan. I have some reservations about this
approach, but unless someone gives a -1 I think it is the best path.



>> 3) go the full circle: new releases of A::R and A::SL, then another modperl-RC
>>
>>
>> Further, it seems to me that MP_AP_PREFIX, MP_AP_DESTDIR, MP_APR_CONFIG and
>> MP_APR_LIB are all historical cruft and should be removed. Why do we need
>> dozens of ways to build modperl. The apxs command should know all the answers
>> of how to build and where to install modperl.
>>
>>> > Another funny discovery I made in our top-level Makefile.PL. There is a
>>> > function named win32_fetch_apxs ...
>>>
>>> I didn't realize that the top-level Makefile.PL actually fetches apxs for
>>> you if you don't have it, but it seems worth leaving in if I understand
>>> things correctly:
>>>
>>> My understanding is that apxs is required for building modules likes
>>> mod_perl and libapreq and that it normally gets installed with Apache httpd
>>> but doesn't get installed on Win32, hence the existence of that separate
>>> apxs_win32.tar.gz package.
>>
>> Yes, apxs is needed to answer questions like "Which C-compiler should be used
>> and which options it should be passed?" or "Where is the httpd binary
>> installed and where do modules go to?" or "Which httpd include files should be
>> used?" apxs can actually do a bit more. But such are the questions we ask it.
>> To answer them apxs here refers to a file share/build/config_vars.mk installed
>> with httpd. The absolute path of that file is hard-wired in apxs. So, apxs is
>> tightly bound to the httpd modperl is built for.
>>
>> So, we have 2 options. We could either update the stuff at
>> http://perl.apache.org/dist/win32-bin and provide a working modern combination
>> of perl, httpd and modperl for win32 (and perhaps 64bit).
>>
>> Or we could drop the stuff. Keeping it as is is a bit embarrassing, I feel.
>>
>>> (I again haven't applied my patch myself because I'm not sure how to go
>>> about patching Reload and SizeLimit. I see they're downloaded into my
>>> mod_perl working copy as "externals", but can I commit changes from there?
>>
>> I think you can
>>
>>  cd Apache-Reload && svn ci ...
>>
>> Torsten Förtsch
>>
>> --
>> Need professional modperl support? Hire me! (http://foertsch.name)
>>
>> Like fantasy? http://kabatinte.net
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 19, 2012, 2:35 PM

Post #6 of 12 (948 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

Torsten Förtsch wrote on 2012-02-19:
> How to proceed from here is a question we'd have to ask Fred. I see 3
> options:
>
> 1) push out RC2 as is as 2.0.6
>
> that would make Steve unhappy and we need another +1 in any case. The
> reasoning for this solution is that the bug in A::R and A::SL sits
> there for years and has survived several public releases. Two thirds
> of all of the SVN commits came in after the one that introduced the bug.
>

Not so long ago (mod_perl-2.0.4) Apache-Reload wasn't bundled with mod_perl, so I had to install it separately, and wasn't unhappy with needing to specify the -httpd option since it was a separate installation.

But now that it's bundled, it ought to build and test correctly. In 2.0.5 the top-level Makefile didn't run the A::R tests so I guess it got past me that it wasn't working, but now that the top-level Makefile does run A::R's tests it's annoying for it not to work, so I wouldn't like this option. (A::SL doesn't affect me at all since the winnt mpm is threaded anyway.)


> 2) commit Steve's changes to A::R and A::SL and roll another RC with them
>
> Since these changes affect only the way modperl communicates MP_APXS
> to bundled submodules at build time and nothing else one could argue
> to avoid the overhead of creating 2 new releases and bundle the
> patched versions.
>
> This is the option I'd prefer.
>

I think that's the best solution too, not least since the state of A::R in RC2 seems a little wonky anyway, claiming to be 0.11, but not including the last changed put into 0.11.


> 3) go the full circle: new releases of A::R and A::SL, then another
> modperl-RC
>
>
> Further, it seems to me that MP_AP_PREFIX, MP_AP_DESTDIR,
> MP_APR_CONFIG and MP_APR_LIB are all historical cruft and should be
> removed. Why do we need dozens of ways to build modperl. The apxs
> command should know all the answers of how to build and where to install modperl.
>

I wondered the same myself, but I'm not so sure now after looking at http://perl.apache.org/docs/2.0/user/install/install.html#Non_Boolean_Build_Options

They do each have a specific purpose, e.g. MP_AP_PREFIX can be useful when building against httpd built in a source directory but not yet installed, MP_AP_DESTDIR is to assist package maintainers, etc.

But it seems like MP_APXS is the best way to proceed when doing a normal build with an installed httpd, and it is what the INSTALL file recommends, so my fixes to make MP_APXS work on Win32 are worthwhile.


>>> Another funny discovery I made in our top-level Makefile.PL. There
>>> is a function named win32_fetch_apxs ...
>>
>> I didn't realize that the top-level Makefile.PL actually fetches
>> apxs for you if you don't have it, but it seems worth leaving in if
>> I understand things correctly:
>>
>> My understanding is that apxs is required for building modules likes
>> mod_perl and libapreq and that it normally gets installed with
>> Apache httpd but doesn't get installed on Win32, hence the existence
>> of that separate apxs_win32.tar.gz package.
>
> Yes, apxs is needed to answer questions like "Which C-compiler should
> be used and which options it should be passed?" or "Where is the httpd
> binary installed and where do modules go to?" or "Which httpd include
> files should be used?" apxs can actually do a bit more. But such are
> the questions we ask it.
> To answer them apxs here refers to a file share/build/config_vars.mk
> installed with httpd. The absolute path of that file is hard-wired in
> apxs. So, apxs is tightly bound to the httpd modperl is built for.
>
> So, we have 2 options. We could either update the stuff at
> http://perl.apache.org/dist/win32-bin and provide a working modern
> combination of perl, httpd and modperl for win32 (and perhaps 64bit).
>
> Or we could drop the stuff. Keeping it as is is a bit embarrassing, I
> feel.

I agree that the Perl-5.8-win32-bin and perl-win32-bin packages are embarrassingly out of date. I'm happy to upload new Apache+Perl+mod_perl packages as and when I build them for my own use (normally for each new 5.X.0 release of perl, and for each new release of mod_perl, with whatever Apache httpd is current at the time) if that would be useful, or we can simply drop them altogether.

But the apxs_win32 package has to stay since there is no other apxs that I know of for Win32!


SteveHay at planit

Feb 19, 2012, 2:41 PM

Post #7 of 12 (951 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

Fred Moyer wrote on 2012-02-19:
> 2012/2/19 Torsten Förtsch <torsten.foertsch [at] gmx>:
>> 2) commit Steve's changes to A::R and A::SL and roll another RC with
>> them
>>
>> Since these changes affect only the way modperl communicates MP_APXS to
>> bundled submodules at build time and nothing else one could argue to
>> avoid the overhead of creating 2 new releases and bundle the patched
>> versions.
>>
>> This is the option I'd prefer.
>
> I prefer this also. I'm not sure how to reconcile this in the Changes
> file for both modules though. We could add them to the tagged versions
> in svn and update the Changes file there, but then the exact files
> shipped with mod_perl and what is on CPAN won't match up for
> Makefile.PL. I could see this as being viewed as a bad practice, but
> since the change is to the Makefile.PL only, I think breaking the
> rules in this instance only is the pragmatic approach.
>

Would it help to set the $VERSIONs to 0.11_01 and 0.96_01 in 2.0.6 to distinguish them from the CPAN releases?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 19, 2012, 2:41 PM

Post #8 of 12 (948 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

Fred Moyer wrote on 2012-02-19:
> 2012/2/19 Fred Moyer <fred [at] redhotpenguin>:
>> 2012/2/19 Torsten Förtsch <torsten.foertsch [at] gmx>:
>>> 2) commit Steve's changes to A::R and A::SL and roll another RC
>>> with them
>>>
>>> Since these changes affect only the way modperl communicates MP_APXS
>>> to bundled submodules at build time and nothing else one could argue
>>> to avoid the overhead of creating 2 new releases and bundle the
>>> patched versions.
>>>
>>> This is the option I'd prefer.
>>
>> I prefer this also.  I'm not sure how to reconcile this in the Changes
>> file for both modules though. We could add them to the tagged versions
>> in svn and update the Changes file there, but then the exact files
>> shipped with mod_perl and what is on CPAN won't match up for
>> Makefile.PL.  I could see this as being viewed as a bad practice, but
>> since the change is to the Makefile.PL only, I think breaking the rules
>> in this instance only is the pragmatic approach.
>
> Adding a +1 to this plan. I have some reservations about this
> approach, but unless someone gives a -1 I think it is the best path.
>

Not sure that I formally have a vote, but I'll give it my +1 FWIW anyway :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 20, 2012, 3:36 AM

Post #9 of 12 (949 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

On Sunday, 19 February 2012 22:35:21 Steve Hay wrote:
> Torsten Förtsch wrote on 2012-02-19:
> > How to proceed from here is a question we'd have to ask Fred. I see 3
> > options:
> >
> > 1) push out RC2 as is as 2.0.6
> > ...
> Not so long ago (mod_perl-2.0.4) Apache-Reload wasn't bundled with mod_perl,
> so I had to install it separately, and wasn't unhappy with needing to
> specify the -httpd option since it was a separate installation.

I wasn't aware of that.

> But now that it's bundled, it ought to build and test correctly. ...

I completely agree.

> > 2) commit Steve's changes to A::R and A::SL and roll another RC with
> > them
> > ...
> I think that's the best solution too, not least since the state of A::R in
> RC2 seems a little wonky anyway, claiming to be 0.11, but not including the
> last changed put into 0.11.

I like your idea about _01 versions.

> >>> Another funny discovery I made in our top-level Makefile.PL. There
> >>> is a function named win32_fetch_apxs ...
> > So, we have 2 options. We could either update the stuff at
> > http://perl.apache.org/dist/win32-bin and provide a working modern
> > combination of perl, httpd and modperl for win32 (and perhaps 64bit).
> >
> > Or we could drop the stuff. Keeping it as is is a bit embarrassing, I
> > feel.
>
> I agree that the Perl-5.8-win32-bin and perl-win32-bin packages are
> embarrassingly out of date. I'm happy to upload new Apache+Perl+mod_perl
> packages as and when I build them for my own use

That would be really great!

Torsten Förtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 20, 2012, 11:32 PM

Post #10 of 12 (947 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

2012/2/20 Torsten Förtsch <torsten.foertsch [at] gmx>:
>> > 2) commit Steve's changes to A::R and A::SL and roll another RC with
>> > them
>> > ...
>> I think that's the best solution too, not least since the state of A::R in
>> RC2 seems a little wonky anyway, claiming to be 0.11, but not including the
>> last changed put into 0.11.

Huh, you're right. Looks like my fault also. Not quite sure how that happened.

=item 0.11 August 21, 2010

Add Apache-Test 1.34 dependency.
[Phred]

> I like your idea about _01 versions.

Given the uncovering of this other Apache-Reload issue, I'm more
inclined now to ship the updates to A:R and A:SL and then roll RC3.
Either way those changes should be committed to trunk I would think.
I can roll those other releases if you want to make those commits
Steve. I know this will slow down the release a bit, but shouldn't be
too much longer.

>
>> >>> Another funny discovery I made in our top-level Makefile.PL. There
>> >>> is a function named win32_fetch_apxs ...
>> > So, we have 2 options. We could either update the stuff at
>> > http://perl.apache.org/dist/win32-bin and provide a working modern
>> > combination of perl, httpd and modperl for win32 (and perhaps 64bit).
>> >
>> > Or we could drop the stuff. Keeping it as is is a bit embarrassing, I
>> > feel.
>>
>> I agree that the Perl-5.8-win32-bin and perl-win32-bin packages are
>> embarrassingly out of date. I'm happy to upload new Apache+Perl+mod_perl
>> packages as and when I build them for my own use
>
> That would be really great!
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 21, 2012, 12:24 AM

Post #11 of 12 (951 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

Fred Moyer wrote on 2012-02-21:
> 2012/2/20 Torsten Förtsch <torsten.foertsch [at] gmx>:
>>>> 2) commit Steve's changes to A::R and A::SL and roll another RC
>>>> with them ...
>>> I think that's the best solution too, not least since the state of
>>> A::R in
>>> RC2 seems a little wonky anyway, claiming to be 0.11, but not
>>> including the last changed put into 0.11.
>
> Huh, you're right. Looks like my fault also. Not quite sure how that
> happened.
>
> =item 0.11 August 21, 2010
>
> Add Apache-Test 1.34 dependency.
> [Phred]
>
>> I like your idea about _01 versions.
>
> Given the uncovering of this other Apache-Reload issue, I'm more
> inclined now to ship the updates to A:R and A:SL and then roll RC3.
> Either way those changes should be committed to trunk I would think.
> I can roll those other releases if you want to make those commits
> Steve. I know this will slow down the release a bit, but shouldn't be
> too much longer.
>

Actually, I don't think I was quite correct in saying that RC2 "doesn't contain the last change put into 0.11". It's true that it doesn't have the last "0.11" Changes entry that appears in svn's copy of Changes (and it doesn't actually have that change in the code either), but neither does version 0.11 on CPAN!

I think rather than svn's copy of Changes wrongly lists the first entry of 0.12-dev as the last entry of 0.11.

Anyway, I'll commit my patch, and also fix that slip-up in A::R's Changes file. I'll leave it up to you whether you want to roll new A::R and A::SL releases or not. I'm easy either way.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 21, 2012, 1:06 AM

Post #12 of 12 (948 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 [In reply to]

Steve Hay wrote on 2012-02-21:
> Fred Moyer wrote on 2012-02-21:
>> 2012/2/20 Torsten Förtsch <torsten.foertsch [at] gmx>:
>>>>> 2) commit Steve's changes to A::R and A::SL and roll another RC
>>>>> with them ...
>>>> I think that's the best solution too, not least since the state of
>>>> A::R in
>>>> RC2 seems a little wonky anyway, claiming to be 0.11, but not
>>>> including the last changed put into 0.11.
>>
>> Huh, you're right. Looks like my fault also. Not quite sure how
>> that happened.
>>
>> =item 0.11 August 21, 2010
>>
>> Add Apache-Test 1.34 dependency.
>> [Phred]
>>
>>> I like your idea about _01 versions.
>>
>> Given the uncovering of this other Apache-Reload issue, I'm more
>> inclined now to ship the updates to A:R and A:SL and then roll RC3.
>> Either way those changes should be committed to trunk I would think. I
>> can roll those other releases if you want to make those commits Steve.
>> I know this will slow down the release a bit, but shouldn't be too much
>> longer.
>>
>
> Actually, I don't think I was quite correct in saying that RC2
> "doesn't contain the last change put into 0.11". It's true that it
> doesn't have the last "0.11" Changes entry that appears in svn's copy
> of Changes (and it doesn't actually have that change in the code
> either), but neither does version 0.11 on CPAN!
>
> I think rather than svn's copy of Changes wrongly lists the first
> entry of 0.12-dev as the last entry of 0.11.
>
> Anyway, I'll commit my patch, and also fix that slip-up in A::R's
> Changes file. I'll leave it up to you whether you want to roll new
> A::R and A::SL releases or not. I'm easy either way.
>

Committed now as revisions 1291665-7. In the course of committing I found that the more up to date versions of A::R and A::SL in svn (compared with RC2) wouldn't actually have suffered the problem that I've just fixed anyway because their check_for_apache_test() functions didn't return 0 when the environment is not set correctly anyway -- that code was removed in 1023549 and 1023551, but hadn't made it into RC2! However, I committed the changes anyway so that -apxs gets set correctly rather than wrongly in case anything else wants to rely on it now or in the future.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

ModPerl dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.