You are viewing a plain text version of this content. The canonical link for it is here.
Posted to testers@httpd.apache.org by "William A. Rowe, Jr." <wr...@apache.org> on 2005/10/10 06:42:43 UTC
[pre-release] 2.0.55 *candidate* available for testing
The httpd-2.0.55 candidate, including win32 source .zip and installers*,
is now available for testing at
http://httpd.apache.org/dev/dist/
Please review this candidate, and when responding, indicate the precise
operating system that you have tested.
Thank you for your assistance!
Bill
* note that win32 binary installers were uploaded only at this hour, and
it will take up to another two hours for the public server to resync.
Thanks for your patience.
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
My appologies; I should have provided this with the announcement to
testers@ and dev@, to avoid confusion;
http://httpd.apache.org/dev/dist/CHANGES_2.0.55
includes the summary of the APR libraries as well as HTTP Server,
since 2.0.54 (apr 0.9.6).
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brian Pane <br...@apache.org>.
On Oct 10, 2005, at 7:32 AM, William A. Rowe, Jr. wrote:
> Brian Pane wrote:
>
>> I encountered lots of errors in perl-framework's t/TEST with prefork
>> on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
>> are due to httpd-2.0.55 problems or just problems with my Perl
>> installation.
>>
>
> Hmmm... review this bug (not fixed in 0.9.7, afaict);
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34332
It looks like most of the errors I saw were due to environmental
problems. I just cleaned up my Perl installation on OS X, and
now there's just one test case that's failing now: test 10 of
t/apache/limits.t.
I _think_ the fix for 34332 is in apr-0.9.7; the CHANGES file
includes:
*) Fix issue with poll() followed by net I/O yielding EAGAIN on
Mac OS 10.4 (Darwin 8). [Wilfredo Sanchez]
I probably won't be able to look at that failed test case in limits.t in
detail for a few days. If anybody else with OS X has time to test
2.0.55 before then, I'd be grateful.
Thanks,
Brian
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian Pane wrote:
>
> I encountered lots of errors in perl-framework's t/TEST with prefork
> on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
> are due to httpd-2.0.55 problems or just problems with my Perl
> installation.
Hmmm... review this bug (not fixed in 0.9.7, afaict);
http://issues.apache.org/bugzilla/show_bug.cgi?id=34332
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brian Pane <br...@apache.org>.
On Oct 10, 2005, at 2:22 AM, Graham Leggett wrote:
> Brian Pane said:
>
>
>> I encountered lots of errors in perl-framework's t/TEST with prefork
>> on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
>> are due to httpd-2.0.55 problems or just problems with my Perl
>> installation.
>>
>
> I ran the build/binbuild.sh script, and httpd built clean on my
> Darwin 8.2.0.
>
> I didn't see any tests being run though, is the test suite fired
> off from
> the binbuild script?
The test suite has to be downloaded and run separately. Basically,
- do a "make install" of the httpd
- checkout asf/repos/httpd/test/trunk from SVN
- cd to the perl-framework subdirectory
- perl Makefile.pl -apxs /path/to/the/httpd/installation/bin/apxs
- ./t/TEST
Brian
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Brian Pane said:
> I encountered lots of errors in perl-framework's t/TEST with prefork
> on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
> are due to httpd-2.0.55 problems or just problems with my Perl
> installation.
I ran the build/binbuild.sh script, and httpd built clean on my Darwin 8.2.0.
I didn't see any tests being run though, is the test suite fired off from
the binbuild script?
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brian Pane <br...@apache.org>.
Tested successfully on Linux 2.6.13/x86_64 (Fedora Core 4) with
both worker and prefork MPMs.
I encountered lots of errors in perl-framework's t/TEST with prefork
on Darwin 8.2.0/PPC (OS X 10.4.2). I don't yet know whether these
are due to httpd-2.0.55 problems or just problems with my Perl
installation.
Brian
On Oct 9, 2005, at 9:42 PM, William A. Rowe, Jr. wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and
> installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the
> precise
> operating system that you have tested.
>
> Thank you for your assistance!
>
> Bill
>
> * note that win32 binary installers were uploaded only at this
> hour, and
> it will take up to another two hours for the public server to
> resync.
> Thanks for your patience.
>
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 09.54 skrev Oden Eriksson:
> måndag 10 oktober 2005 06.42 skrev William A. Rowe, Jr.:
> > The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> > is now available for testing at
> >
> > http://httpd.apache.org/dev/dist/
> >
> > Please review this candidate, and when responding, indicate the precise
> > operating system that you have tested.
>
> There's no fix for CAN-2005-2088 in this one.
Duh! Too early in the morning...
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 06.42 skrev William A. Rowe, Jr.:
> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the precise
> operating system that you have tested.
There's no fix for CAN-2005-2088 in this one.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by The Doctor <do...@doctor.nl2k.ab.ca>.
On Mon, Oct 10, 2005 at 10:11:13AM -0600, Brad Nicholes wrote:
> +1 NetWare
>
> Brad
>
BSD/OS using Openssl 0.9.8 is spot on!
> >>> On 10/9/2005 at 10:42:43 pm, in message
> <43...@apache.org>,
> wrowe@apache.org wrote:
> > The httpd-2.0.55 candidate, including win32 source .zip and
> installers*,
> > is now available for testing at
> >
> > http://httpd.apache.org/dev/dist/
> >
> > Please review this candidate, and when responding, indicate the
> precise
> > operating system that you have tested.
> >
> > Thank you for your assistance!
> >
> > Bill
> >
> > * note that win32 binary installers were uploaded only at this hour,
> and
> > it will take up to another two hours for the public server to
> resync.
> > Thanks for your patience.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
> For additional commands, e-mail: testers-help@httpd.apache.org
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
Member - Liberal International
This is doctor@nl2k.ab.ca Ici doctor@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Better to serve in Heaven that to Rule in Hell.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by The Doctor <do...@doctor.nl2k.ab.ca>.
On Mon, Oct 10, 2005 at 10:11:13AM -0600, Brad Nicholes wrote:
> +1 NetWare
>
> Brad
>
BSD/OS using Openssl 0.9.8 is spot on!
> >>> On 10/9/2005 at 10:42:43 pm, in message
> <43...@apache.org>,
> wrowe@apache.org wrote:
> > The httpd-2.0.55 candidate, including win32 source .zip and
> installers*,
> > is now available for testing at
> >
> > http://httpd.apache.org/dev/dist/
> >
> > Please review this candidate, and when responding, indicate the
> precise
> > operating system that you have tested.
> >
> > Thank you for your assistance!
> >
> > Bill
> >
> > * note that win32 binary installers were uploaded only at this hour,
> and
> > it will take up to another two hours for the public server to
> resync.
> > Thanks for your patience.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
> For additional commands, e-mail: testers-help@httpd.apache.org
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
Member - Liberal International
This is doctor@nl2k.ab.ca Ici doctor@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Better to serve in Heaven that to Rule in Hell.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brad Nicholes <BN...@novell.com>.
+1 NetWare
Brad
>>> On 10/9/2005 at 10:42:43 pm, in message
<43...@apache.org>,
wrowe@apache.org wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and
installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the
precise
> operating system that you have tested.
>
> Thank you for your assistance!
>
> Bill
>
> * note that win32 binary installers were uploaded only at this hour,
and
> it will take up to another two hours for the public server to
resync.
> Thanks for your patience.
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Jarrod <ja...@netleader.com.au>.
+1 FreeBSD (4.11-RELEASE-p12 i386, OpenSSL 0.9.7a)
Jarrod.
On Sun, 9 Oct 2005, William A. Rowe, Jr. wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the precise
> operating system that you have tested.
>
> Thank you for your assistance!
>
> Bill
>
> * note that win32 binary installers were uploaded only at this hour, and
> it will take up to another two hours for the public server to resync.
> Thanks for your patience.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
> For additional commands, e-mail: testers-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
My appologies; I should have provided this with the announcement to
testers@ and dev@, to avoid confusion;
http://httpd.apache.org/dev/dist/CHANGES_2.0.55
includes the summary of the APR libraries as well as HTTP Server,
since 2.0.54 (apr 0.9.6).
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: testers-unsubscribe@httpd.apache.org
For additional commands, e-mail: testers-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brad Nicholes <BN...@novell.com>.
+1 NetWare
Brad
>>> On 10/9/2005 at 10:42:43 pm, in message
<43...@apache.org>,
wrowe@apache.org wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and
installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the
precise
> operating system that you have tested.
>
> Thank you for your assistance!
>
> Bill
>
> * note that win32 binary installers were uploaded only at this hour,
and
> it will take up to another two hours for the public server to
resync.
> Thanks for your patience.
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Thank you everyone for testing, especially the infrateam for picking
this up on Ajax and really stressing it under mod_mbox (in spite of
a few more fixes required to mbox's mime processing :)
Although the site is updated, starting the clock on the announce till
early tomorrow aftn (america time) so that our proxies start to catch up.
FYI I staged, did not svn up the 1.3.34 announce site work for Jim's
behalf - so we are 1/2 there.
Docs team; feel free to ressurect or add Announcement2.0.txt/.html.lang,
and even Announcement1.3.txt/.html.lang - the security notes in 2.0 I'm
sure are quite a bit of work to translate. These are all in the
https://svn.apache.org/repos/asf/httpd/httpd/dist/ repository. You're
also welcome to work up Announcement2.1-beta.txt/.html.lang if you like.
Note I've eliminated the Announcement's "German and Japanese
translations are available" - and rather indicate that additional
translations may become available so that users bother to check,
should they require a native translation.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Thank you everyone for testing, especially the infrateam for picking
this up on Ajax and really stressing it under mod_mbox (in spite of
a few more fixes required to mbox's mime processing :)
Although the site is updated, starting the clock on the announce till
early tomorrow aftn (america time) so that our proxies start to catch up.
FYI I staged, did not svn up the 1.3.34 announce site work for Jim's
behalf - so we are 1/2 there.
Docs team; feel free to ressurect or add Announcement2.0.txt/.html.lang,
and even Announcement1.3.txt/.html.lang - the security notes in 2.0 I'm
sure are quite a bit of work to translate. These are all in the
https://svn.apache.org/repos/asf/httpd/httpd/dist/ repository. You're
also welcome to work up Announcement2.1-beta.txt/.html.lang if you like.
Note I've eliminated the Announcement's "German and Japanese
translations are available" - and rather indicate that additional
translations may become available so that users bother to check,
should they require a native translation.
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Sander Temme <sc...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Oct 10, 2005, at 9:35 AM, William A. Rowe, Jr. wrote:
> Sander Temme wrote:
>
>> On Oct 9, 2005, at 9:42 PM, William A. Rowe, Jr. wrote:
>>
>>> The httpd-2.0.55 candidate, including win32 source .zip and
>>> installers*,
>>>
>> As of 17:59 CEST (15 minutes ago), 2.0.55 is running on
>> www.apache.org. Please report any anomalies.
>>
>
> Ack, starting clock with 72 hours to GA, contingent upon an absence
> of problem reports (specificially regressions).
Six more cores since the last update of mod_mbox. Then twenty more
appeared with exactly the same timestamp: probably some bot pounding
the site.
Quick story: all the cores I've analyzed are mod_mbox crashes. None
in other parts of httpd.
+1 for GA based on running for 72 hours on www.apache.org without
crashes in the distributed code.
S.
Brief analysis of some of the cores follows:
/raid1/httpd-cores/core.5885
#0 mbox_mime_decode_body (p=0x0, cte=CTE_NONE, body=0x0, len=0) at
mod_mbox_mime.c:290
#1 0x2000000001011110 in mbox_mime_get_body (p=0x60000000002509c8,
m=0x6000000000063130) at mod_mbox_mime.c:299
#2 0x200000000100d2e0 in mbox_static_message (r=0x6000000000250a30,
f=0x60000000001ed530) at mod_mbox_out.c:1151
#3 0x2000000001008ca0 in mbox_file_handler (r=0x6000000000250a30) at
mod_mbox_file.c:231
#4 0x4000000000035f90 in ap_run_handler (r=0x6000000000250a30) at
config.c:153
#5 0x4000000000036f70 in ap_invoke_handler (r=0x6000000000250a30) at
config.c:317
#6 0x400000000002fb00 in ap_process_request (r=0x6000000000250a30)
at http_request.c:226
#7 0x4000000000024bf0 in ap_process_http_connection
(c=0x60000000001db350) at http_core.c:233
#8 0x400000000004db00 in ap_run_process_connection
(c=0x60000000001db350) at connection.c:43
#9 0x4000000000032910 in child_main (child_num_arg=27976) at
prefork.c:610
#10 0x4000000000032be0 in make_child (s=0x6000000000047788, slot=360)
at prefork.c:704
#11 0x4000000000033180 in perform_idle_server_maintenance (p=0x6) at
prefork.c:839
#12 0x4000000000033fc0 in ap_mpm_run (_pconf=0x600000000000bc68,
plog=0x6000000000042298, s=0x0) at prefork.c:863
#13 0x4000000000041f60 in main (argc=2, argv=0x60000fffffffb3e8) at
main.c:618
(gdb) print r->unparsed_uri
$2 = 0x6000000000251f00 "/mod_mbox/httpd-users/200310.mbox/%3CBAY2-
F103MOEYzk8TRA00006ddd@hotmail.com%3E"
/raid1/httpd-cores/core.28450
#0 get_base_uri (r=0x6000000000215748) at mod_mbox.c:197
#1 0x2000000001007a10 in get_base_path (r=0x6000000000215748) at
mod_mbox.c:178
#2 0x200000000100cfa0 in mbox_static_message (r=0x60000000002155d0,
f=0x60000000001f87b8) at mod_mbox_out.c:1051
#3 0x2000000001008ca0 in mbox_file_handler (r=0x60000000002155d0) at
mod_mbox_file.c:231
#4 0x4000000000035f90 in ap_run_handler (r=0x60000000002155d0) at
config.c:153
#5 0x4000000000036f70 in ap_invoke_handler (r=0x60000000002155d0) at
config.c:317
#6 0x400000000002fb00 in ap_process_request (r=0x60000000002155d0)
at http_request.c:226
#7 0x4000000000024bf0 in ap_process_http_connection
(c=0x60000000001db530) at http_core.c:233
#8 0x400000000004db00 in ap_run_process_connection
(c=0x60000000001db530) at connection.c:43
#9 0x4000000000032910 in child_main (child_num_arg=27976) at
prefork.c:610
#10 0x4000000000032be0 in make_child (s=0x6000000000047788, slot=29)
at prefork.c:704
#11 0x4000000000033180 in perform_idle_server_maintenance (p=0x1) at
prefork.c:839
#12 0x4000000000033fc0 in ap_mpm_run (_pconf=0x0,
plog=0x6000000000042298, s=0x0) at prefork.c:863
#13 0x4000000000041f60 in main (argc=2, argv=0x60000fffffffb3e8) at
main.c:618
(gdb) print r->unparsed_uri
$1 = 0x0
(gdb) print r->header_only
$3 = 1
/raid1/httpd-cores/core.19623
#0 get_base_uri (r=0x6000000000213778) at mod_mbox.c:197
#1 0x2000000001007a10 in get_base_path (r=0x6000000000213778) at
mod_mbox.c:178
#2 0x200000000100cfa0 in mbox_static_message (r=0x6000000000213600,
f=0x6000000000224958) at mod_mbox_out.c:1051
#3 0x2000000001008ca0 in mbox_file_handler (r=0x6000000000213600) at
mod_mbox_file.c:231
#4 0x4000000000035f90 in ap_run_handler (r=0x6000000000213600) at
config.c:153
#5 0x4000000000036f70 in ap_invoke_handler (r=0x6000000000213600) at
config.c:317
#6 0x400000000002fb00 in ap_process_request (r=0x6000000000213600)
at http_request.c:226
#7 0x4000000000024bf0 in ap_process_http_connection
(c=0x60000000001db530) at http_core.c:233
#8 0x400000000004db00 in ap_run_process_connection
(c=0x60000000001db530) at connection.c:43
#9 0x4000000000032910 in child_main (child_num_arg=27976) at
prefork.c:610
#10 0x4000000000032be0 in make_child (s=0x6000000000047788, slot=185)
at prefork.c:704
#11 0x4000000000033180 in perform_idle_server_maintenance (p=0x2) at
prefork.c:839
#12 0x4000000000033fc0 in ap_mpm_run (_pconf=0x0,
plog=0x6000000000042298, s=0x0) at prefork.c:863
#13 0x4000000000041f60 in main (argc=2, argv=0x60000fffffffb3e8) at
main.c:618
There are quite a few of these. Here's the full request_rec of this
particular one:
(gdb) print *r
$1 = {pool = 0x60000000002153a7, connection = 0x0, server =
0x6000000000213598, next = 0x6440073f170, prev = 0x1f800000001, main
= 0x13aa, the_request = 0x5a867f <Address 0x5a867f out of bounds>,
assbackwards = 2065, proxyreq = 0, header_only = 1, protocol =
0x1fc20e <Address 0x1fc20e out of bounds>, proto_num = 0, hostname =
0x402f817f63900 <Address 0x402f817f63900 out of bounds>,
request_time = 1123663468000000, status_line = 0x4028a48dc9280
<Address 0x4028a48dc9280 out of bounds>, status = 3932920, method =
0x0, method_number = 0, allowed = 0, allowed_xmethods = 0x0,
allowed_methods = 0x0, sent_bodyct = 0, bytes_sent = 0, mtime = 0,
chunked = 2182016, range = 0x0, clength = 0, remaining = 0,
read_length = 65536, read_body = 2, read_chunked = 0,
expecting_100 = 2041752, headers_in = 0x6000000000214568,
headers_out = 0x60000000001f2738, err_headers_out =
0x6000000000200d58, subprocess_env = 0x6000000000214928, notes =
0x6000000000214950,
content_type = 0x6000000000214928 "�n\001", handler = 0x0,
content_encoding = 0x0, content_languages = 0x60000000002138b0,
vlist_validator = 0x6000000000213598 "��\035",
user = 0x8 <Address 0x8 out of bounds>, ap_auth_type =
0x2074636500000002 <Address 0x2074636500000002 out of bounds>,
no_cache = 2177232, no_local_copy = 1610612736, unparsed_uri = 0x0,
uri = 0x0,
filename = 0x6000000000213598 "��\035", canonical_filename =
0x900000018 <Address 0x900000018 out of bounds>, path_info =
0x2020202000000019 <Address 0x2020202000000019 out of bounds>,
args = 0x6000000000213a08 "", finfo = {pool = 0x2e6174720024012a,
valid = 1, protection = 1865311592, filetype = APR_CHR, user =
795178089, group = 8, inode = 1747857971,
device = 8386658473162859858, nlink = 1919242272, size =
7598809965127562350, csize = 3414965976753469038, atime =
18949104999, mtime = 8675450682576495990, ctime = 2314885856696991749,
fname = 0x2f3a707474682020 <Address 0x2f3a707474682020 out of
bounds>, name = 0x617472616b616a2f <Address 0x617472616b616a2f out of
bounds>, filehand = 0x2e6568636170612e}, parsed_uri = {
scheme = 0x657469732f67726f <Address 0x657469732f67726f out of
bounds>, hostinfo = 0x6f766e697465672f <Address 0x6f766e697465672f
out of bounds>,
user = 0x6d74682e00000002 <Address 0x6d74682e00000002 out of
bounds>, password = 0x6572696400000003 <Address 0x6572696400000003
out of bounds>,
hostname = 0x616d726500000008 <Address 0x616d726500000008 out of
bounds>, port_str = 0x746e656e <Address 0x746e656e out of bounds>,
path = 0x65766c6f766e6974 <Address 0x65766c6f766e6974 out of
bounds>, query = 0x72617262696c2f64 <Address 0x72617262696c2f64 out
of bounds>,
fragment = 0x20206c6d74682e79 <Address 0x20206c6d74682e79 out of
bounds>, hostent = 0x2020202020202020, port = 8224, is_initialized =
0, dns_looked_up = 0, dns_resolved = 0},
used_path_info = 1781477178, per_dir_config = 0x6863617000000007,
request_config = 0x69732f67726f2e65, htaccess = 0x617262696c2f6574,
output_filters = 0xa6c6d74682e7972,
input_filters = 0x7463657269646552, proto_output_filters =
0x656e616d72655020, proto_input_filters = 0x6000000000214c00,
eos_sent = 2182150}
Guess that's gonna look real good in YOUR mailer... note a lot of
garbage, and header_only is set. It's a HEAD request.
Couple more with the same issue. core.7456 broke ata different point:
#0 mbox_raw_message (r=0x6000000000238720, f=0x31) at mod_mbox_out.c:
966
#1 0x2000000001008cf0 in mbox_file_handler (r=0x6000000000238720) at
mod_mbox_file.c:231
#2 0x4000000000035f90 in ap_run_handler (r=0x6000000000238720) at
config.c:153
#3 0x4000000000036f70 in ap_invoke_handler (r=0x6000000000238720) at
config.c:317
#4 0x400000000002fb00 in ap_process_request (r=0x6000000000238720)
at http_request.c:226
#5 0x4000000000024bf0 in ap_process_http_connection
(c=0x60000000001db530) at http_core.c:233
#6 0x400000000004db00 in ap_run_process_connection
(c=0x60000000001db530) at connection.c:43
#7 0x4000000000032910 in child_main (child_num_arg=27976) at
prefork.c:610
#8 0x4000000000032be0 in make_child (s=0x6000000000047788, slot=118)
at prefork.c:704
#9 0x4000000000033180 in perform_idle_server_maintenance (p=0x1) at
prefork.c:839
#10 0x4000000000033fc0 in ap_mpm_run (_pconf=0x0,
plog=0x6000000000042298, s=0x0) at prefork.c:863
#11 0x4000000000041f60 in main (argc=2, argv=0x60000fffffffb3e8) at
main.c:618
(gdb) print r->unparsed_uri
$2 = 0x6000000000239bf0 "/mod_mbox/ws-fx-dev/200501.mbox/raw/
<41...@parasoft.com>/axis.html"
core.13402 breaks in the same place with the following request:
(gdb) print r->unparsed_uri
$2 = 0x60000000003554f0 "/mod_mbox/ws-axis-c-user/200412.mbox/raw/%
3CEAA42CA41CFA78419786AF09337DEBF804B43B1A@edmb003.edm-b.edm.dsh.de%
3E/%5C%5C%5C"
core.11704, same line, the following request:
(gdb) print r->unparsed_uri
$1 = 0x60000000002480f0 "/mod_mbox/ws-axis-c-user/200412.mbox/raw/%
3CEAA42CA41CFA78419786AF09337DEBF804B43B1A@edmb003.edm-b.edm.dsh.de%
3E/%5C%5C%5C"
Etc. etc.
- --
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDTqNXnjkrwtLH+RIRAtJ5AJ95uUxQsgWgmr/iJFp/Yzep5WZjngCfcmMx
gpilgLS9KUEVEIJ3dMFDEJE=
=wg45
-----END PGP SIGNATURE-----
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sander Temme wrote:
>
> On Oct 9, 2005, at 9:42 PM, William A. Rowe, Jr. wrote:
>
>> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
>
> As of 17:59 CEST (15 minutes ago), 2.0.55 is running on www.apache.org.
> Please report any anomalies.
Ack, starting clock with 72 hours to GA, contingent upon an absence
of problem reports (specificially regressions).
> We're now also running a very current version of mod_mbox (tagged
> www.apache.org-20051010). No cores so far but I'll keep an eye on it.
Nice! Hope this licks the earlier chaos.
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Sander Temme <sc...@apache.org>.
On Oct 9, 2005, at 9:42 PM, William A. Rowe, Jr. wrote:
> The httpd-2.0.55 candidate, including win32 source .zip and
> installers*,
As of 17:59 CEST (15 minutes ago), 2.0.55 is running on
www.apache.org. Please report any anomalies.
We're now also running a very current version of mod_mbox (tagged
www.apache.org-20051010). No cores so far but I'll keep an eye on it.
S.
--
sander@temme.net http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 16.27 skrev William A. Rowe, Jr.:
> Oden Eriksson wrote:
> > And some investigations told me it requires apr 0.9.7, maybe the
> > autotools stuff should check for this or be documented?
>
> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
> announce, certainly, and on the downloads page README - would that
> suffice?
Yep. Thanks.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 17.28 skrev William A. Rowe, Jr.:
> Brian Akins wrote:
> > William A. Rowe, Jr. wrote:
> >> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
> >> announce, certainly, and on the downloads page README - would that
> >> suffice?
> >
> > How horrible would it be to have the apr_reslist_invalidate patch
> > applied to the bundled apr?
>
> I'm wondering if we all woke up this morning on different planets :)
I must have :)
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 17.33 skrev William A. Rowe, Jr.:
> Oden Eriksson wrote:
> > i think it's not there :)
>
> Oden, just looked again, would you check your package signature?
>
> b45f16a9878e709497820565d42b00b9 httpd-2.0.55.tar.gz
>
> and ensure that you are building against the included srclib/apr/ and
> not against some system installed 0.9.6 version?
Argh! I looked in the wrong place (wrong changelog). Sorry for the noise.
Anyway, 2.0.55 works for me on my Mandriva boxes.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Oden Eriksson wrote:
>
> i think it's not there :)
Oden, just looked again, would you check your package signature?
b45f16a9878e709497820565d42b00b9 httpd-2.0.55.tar.gz
and ensure that you are building against the included srclib/apr/ and
not against some system installed 0.9.6 version?
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 16.56 skrev Brian Akins:
> Paul Querna wrote:
> > Huh? It is already in 0.9.7 :) I committed it to the 0.9.x branch right
> > after 0.9.6 was released.
>
> Thank you! I guess I didn't check the CHANGELOG closely enough.
i think it's not there :)
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brian Akins <br...@turner.com>.
Paul Querna wrote:
> Huh? It is already in 0.9.7 :) I committed it to the 0.9.x branch right
> after 0.9.6 was released.
Thank you! I guess I didn't check the CHANGELOG closely enough.
<hangs head in shame />
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Paul Querna <ch...@force-elite.com>.
Brian Akins wrote:
> William A. Rowe, Jr. wrote:
>
>>
>> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
>> announce, certainly, and on the downloads page README - would that
>> suffice?
>>
>
> How horrible would it be to have the apr_reslist_invalidate patch
> applied to the bundled apr?
Huh? It is already in 0.9.7 :) I committed it to the 0.9.x branch right
after 0.9.6 was released.
-Paul
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian Akins wrote:
> William A. Rowe, Jr. wrote:
>
>> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
>> announce, certainly, and on the downloads page README - would that
>> suffice?
>>
>
> How horrible would it be to have the apr_reslist_invalidate patch
> applied to the bundled apr?
I'm wondering if we all woke up this morning on different planets :)
$ cd httpd-2.0.55
$ grep -r apr_reslist_invalidate *
srclib/apr-util/include/apr_reslist.h:APU_DECLARE(apr_status_t)
apr_reslist_invalidate(apr_reslist_t *reslist,
srclib/apr-util/misc/apr_reslist.c:APU_DECLARE(apr_status_t)
apr_reslist_invalidate(apr_reslist_t *reslist,
srclib/apr-util/CHANGES: *) Backport the apr_reslist_timeout_set and
apr_reslist_invalidate
Which patch are you thinking about? The next window of opportunity is
apr-0.9.8, which if it's substantial, probably will have its day before
2.0.56.
With several other apr-based projects, including arbitrary patches in
the release tarball is a non-starter. If you have additional patches
for some specific cases, we can consider adding them in dist/httpd/
to patches/apply_to_2.0.55/.
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Brian Akins <br...@turner.com>.
William A. Rowe, Jr. wrote:
>
> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
> announce, certainly, and on the downloads page README - would that
> suffice?
>
How horrible would it be to have the apr_reslist_invalidate patch
applied to the bundled apr?
<ducks and runs />
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55
*candidate* available for testing)
Posted by Graham Leggett <mi...@sharp.fm>.
Luc Pardon said:
> Yes, but what got me confused is that the httpd tarball comes with
> the APR source (hence the docs don't talk about it as being a
> prerequisite) whereas the current spec file requires you to go elsewhere
> and get something that is already there. It seem to me that this kind of
> defeats the purposo of bundling APR.
The APR bundled with source is historical - the APR library grew out of
the httpd code, and was only recently "promoted" to a library in it's own
right.
The removal of APR from the httpd has been discussed a number of times,
and I think will probably happen eventually once APR is widespread on it's
own.
Most of the major distros already distribute httpd and apr separately as
APR v0.9.x and httpd v2.0.x (Redhat does anyway), so in the RPM world this
isn't too much of a surprise to have them separate.
> Agreed on both counts. That (no patches) is one of the reasons why
> I'm building my own.
>
> But I think there are sometimes other differencies than just
> patches, no ? For example, installing into platform-dependent dirs or
> other variations in configure options ? Or init script stuff ?
The spec file has slowly got simpler and simpler, with more and more of
the "special" stuff being removed from the spec file, falling back on the
normal httpd build process.
Ideally the spec file should eventually be trivial, it shouldn't be
necessary to have to move files and directories around in a spec file when
the httpd build process contains an option to choose a directory layout
already.
> I see. But couldn't you leave them sitting in srclib/apr, where
> rpmbuild -tb won't see them ? Or better, merge them into httpd.spec, so
> that rpmbuild -tb will produce apr packages from the bundled code in one
> go ?
There is a drive to get APR to stand on it's own as much as possible.
Combining the packaging with httpd is going backwards on a process that
should eventually see apr removed from the httpd tree entirely.
> From a later message of yours, it seems it's too late already <g>.
I just created a patch for this, just battling to test it (stupid working
directories copied from MacOSX to Fedora grumble).
> As an aside, is there no configure macro somewhere (something like
> APR_VERSION) that would avoid having to hard-code it in httpd.spec.in ?
If there is this would be very useful, will have to investigate.
Regards,
Graham
--
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55
*candidate* available for testing)
Posted by Luc Pardon <lu...@skopos.be>.
Graham Leggett wrote:
>
> Luc Pardon said:
>
> > In that case the 2.0 httpd.spec files should either a) not require
> > pre-installed apr packages and build apr as part of the httpd rpm,
>
> A definite -1 on this. If this were so, httpd could not coexist cleanly
> with other packages that depended on APR.
Definitely. I missed the fact that apr 0.9 and 1.x can coexist.
>
> > or b)
> > build the bundled apr stuff into separate rpm packages itself.
>
> APR is already available as an RPM, both for the 0.9 and 1.x trees, and
> 0.9 and 1.x can be installed simultaneously.
>
> See the binaries/rpm directory in the download section for APR.
>
Yes, but what got me confused is that the httpd tarball comes with
the APR source (hence the docs don't talk about it as being a
prerequisite) whereas the current spec file requires you to go elsewhere
and get something that is already there. It seem to me that this kind of
defeats the purposo of bundling APR.
> > I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK
> > the rpm specs differ in details, so you'd probably have to populate the
> > rpm subdir with working spec files for various platforms (collected
> > after the fact <g>). Or add platform-specific subdirs under rpm/.
>
> Different spec files for different platforms should be avoided as much as
> possible. Each distro will release an httpd version + their custom patches
> for the purposes of that distro anyway, Apache isn't a distro, so can
> release a clean httpd as is without any patches.
Agreed on both counts. That (no patches) is one of the reasons why
I'm building my own.
But I think there are sometimes other differencies than just
patches, no ? For example, installing into platform-dependent dirs or
other variations in configure options ? Or init script stuff ?
Note that I'm not arguing, just wondering. Of course, having
multiple spec files (for different platforms) will break rpmbuild -tb
big time.
>
> > "The httpd.spec file, as included in the tarball, requires apr and
> > apr-util and the corresponding devel packages to be installed as
> > separate rpm's. Although the APR source code is present in the httpd
> > tarball, there are currently no APR spec files. You can't build the APR
> > rpm's from the httpd.spec file either. In other words, if you want to
> > build httpd from the included spec file, you'll first have to go and
> > find the APR rpm's in the usual places and install them."
>
> There are APR spec files in the APR and APR-util archives.
>
> They are removed from the apr tree in the httpd build, as rpm gets
> confused is there is more than one spec file in a tarball (in other words,
> rpmbuild -tb is not possible otherwise).
>
I see. But couldn't you leave them sitting in srclib/apr, where
rpmbuild -tb won't see them ? Or better, merge them into httpd.spec, so
that rpmbuild -tb will produce apr packages from the bundled code in one
go ?
Would there be any objections against the latter ?
After all, httpd.spec already produces the httpd, httpd-devel,
httpd-manual and mod_ssl rpm's. Why not apr, apr-util, apr-devel and
apr-util-devel as well ? Nobody obliges you to install the whole set.
> > If you leave it in, changing the dependencies to properly require
> > 0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So
> > trivial in fact that I'm willing to provide a patch <g>.
>
> Please do :)
>
From a later message of yours, it seems it's too late already <g>.
As an aside, is there no configure macro somewhere (something like
APR_VERSION) that would avoid having to hard-code it in httpd.spec.in ?
Luc
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55
*candidate* available for testing)
Posted by Graham Leggett <mi...@sharp.fm>.
Luc Pardon said:
> In that case the 2.0 httpd.spec files should either a) not require
> pre-installed apr packages and build apr as part of the httpd rpm,
A definite -1 on this. If this were so, httpd could not coexist cleanly
with other packages that depended on APR.
> or b)
> build the bundled apr stuff into separate rpm packages itself.
APR is already available as an RPM, both for the 0.9 and 1.x trees, and
0.9 and 1.x can be installed simultaneously.
See the binaries/rpm directory in the download section for APR.
> I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK
> the rpm specs differ in details, so you'd probably have to populate the
> rpm subdir with working spec files for various platforms (collected
> after the fact <g>). Or add platform-specific subdirs under rpm/.
Different spec files for different platforms should be avoided as much as
possible. Each distro will release an httpd version + their custom patches
for the purposes of that distro anyway, Apache isn't a distro, so can
release a clean httpd as is without any patches.
> "The httpd.spec file, as included in the tarball, requires apr and
> apr-util and the corresponding devel packages to be installed as
> separate rpm's. Although the APR source code is present in the httpd
> tarball, there are currently no APR spec files. You can't build the APR
> rpm's from the httpd.spec file either. In other words, if you want to
> build httpd from the included spec file, you'll first have to go and
> find the APR rpm's in the usual places and install them."
There are APR spec files in the APR and APR-util archives.
They are removed from the apr tree in the httpd build, as rpm gets
confused is there is more than one spec file in a tarball (in other words,
rpmbuild -tb is not possible otherwise).
> Most people building rpm's themselves (as opposed to installing
> pre-built binary rpm's) would IMO be able to cope with that. In fact,
> I'd expect them to have pre-existing spec files anyway.
>
> Therefore, another solution would be to lift httpd.spec out of the
> 2.0.55 tarball altogether (but that's frozen, right?).
>
> If you leave it in, changing the dependencies to properly require
> 0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So
> trivial in fact that I'm willing to provide a patch <g>.
Please do :)
There is one fix I need to make to the httpd.in file as released
concerning the xml doc files. The spec file tries to remove the xml files,
however the build was changed to remove them.
Regards,
Graham
--
[pre-release] rpm spec file (was: Re: [pre-release] 2.0.55 *candidate*
available for testing)
Posted by Luc Pardon <lu...@skopos.be>.
"William A. Rowe, Jr." wrote:
>
> <snip>
> This was a snafu in the way the rpm change was presented, not in the
> tarballs. httpd-2.0's distribution tarball will always contain apr 0.9.
>
> That doesn't mean httpd-2.2 (with apr 1.x) will do the same; that's yet
> to be determined.
In that case the 2.0 httpd.spec files should either a) not require
pre-installed apr packages and build apr as part of the httpd rpm, or b)
build the bundled apr stuff into separate rpm packages itself.
Solution a) would be best if httpd 2.0.55 absolutely requires apr
0.9.7 and nothing else, i.e. does not work with apr 1.2.1 or not even
with 0.9.8 if/when that comes out.
Otherwise, solution b) would be the way to go.
Again, I realize that all this has been discussed at length on this
list. Normally I would look at the archives but the countdown has
started and my time is limited, so it's quicker to ask. For me, that is
...
>
> Coming back to rpm's for the moment; I do *not* mean to suggest that
> this is the best solution for any specific platform or distribution
> method, be it .rpm, .depot, .pkg, .msi, or any other facility.
Wise, very. Any suggestion in that area is likely to spark a flame
war <g>.
>
> <snip>
>
> I'm concerned that the current .spec solution is wrong; it's very
> platform specific (platform meaning deployment mechanics, in this
> case, I'm not slamming non-unix rpm implementations). Perhaps we
> rejigger the tree to
>
> httpd/
> package/
> roll-release/
> win32-msi/
> rpm/
> pkg/
>
> Thoughts?
>
Not really. The current build/rpm seems fine to me, but I wouldn't
mind if it changed either.
I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK
the rpm specs differ in details, so you'd probably have to populate the
rpm subdir with working spec files for various platforms (collected
after the fact <g>). Or add platform-specific subdirs under rpm/.
> In the interim; is this a showstopper? Do we generally do the right
> thing (e.g. without changes, can we package up using the existing
> rpm files?) Obviously 2.0.54 was mispackaged as well, it's minimum
> apr package dependency should have been 0.9.6 apr, not 0.9.5.
>
> Bill
Showstopper probably not, as long as you document that the spec file
is broken, for example:
"The httpd.spec file, as included in the tarball, requires apr and
apr-util and the corresponding devel packages to be installed as
separate rpm's. Although the APR source code is present in the httpd
tarball, there are currently no APR spec files. You can't build the APR
rpm's from the httpd.spec file either. In other words, if you want to
build httpd from the included spec file, you'll first have to go and
find the APR rpm's in the usual places and install them."
Most people building rpm's themselves (as opposed to installing
pre-built binary rpm's) would IMO be able to cope with that. In fact,
I'd expect them to have pre-existing spec files anyway.
Therefore, another solution would be to lift httpd.spec out of the
2.0.55 tarball altogether (but that's frozen, right?).
If you leave it in, changing the dependencies to properly require
0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So
trivial in fact that I'm willing to provide a patch <g>.
Beyond that, any fix I can offer (e.g. to build separate apr
packages) would only be tested on my systems.
Luc Pardon
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Luc Pardon <lu...@skopos.be>.
Colm MacCarthaigh wrote:
>
> On Tue, Oct 11, 2005 at 11:38:03AM +0200, Graham Leggett wrote:
> > Anybody who wants to run the latest version of httpd on their RPM based
> > server,
>
> How many people actually build RPM's is what I'm wondering, given the
> errors that creep in in the releases, and we don't see that many
> complaints, it can't be a very high number. I see a fair amount of
> downloads for the RPM's files themselves, which is what makes me wonder.
>
If this was not a release candidate and/or if this list was not
dev@httpd.apache.org, I would probably not have bothered. I would have
fixed it myself and moved on.
Selfish, I know, but it takes time to go find the right list, check
existing bugs, document your case and then be prepared to go get a
bugzilla password and submit a bug report and a testcase. You also run
the risk of having to face some adverse comments if you miss some fine
point of the group's etiquette (top posting, bottom posting, to snip or
quote in full, ...). Note that I'm not talking about _this_ list, but
developer lists in general. It actually helped that I happen to be a
lurker on this list, so I know it's a cosy place. There are others.
And to be honest, I sometimes find myself thinking: if these people
(in general, not httpd) can't be bothered to ship something that doesn't
build out of the box in the first place, why should I care and what
chances do I have of getting it changed. So you fix, build, install and
move on.
Could that explain part of what you're seeing ?
Luc
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Colm MacCarthaigh said:
> I see people downloading them a fair ammount ( > 400 per day, which is
> actually quite a lot for the binaries section), and I don't see why
> these would discontinue. So, would it be so bad a thing if the release
> tarball wasn't itself buildable?
The release tarball should in itself be buildable, yes. Trouble is I
sometime don't get to test the RPM build on time, and the release goes out
the door with a broken spec file :(
> What is the number of commands it takes to turn an SRPM into a binary
> .rpm ?
rpmbuild --rebuild httpd-2.0.55-1.src.rpm
> I deploy a locally built .deb, and that's much more work, so building
> an rpm locally might be a lot more common than I suspect.
We currently have build scripts/spec file for RPM and for Solais PKG, is
it difficult to get httpd to be built as a .deb "out the box"? I know
precious little about .deb packaging.
> Well to be honest, I'm kind of confused as to why the source tarball
> should be doing any of the packager's work, but I guess that's a
> different argument :-)
RPM has features that make it easy to go from tarball to RPM in a single
step, and follows the principle of least astonishment :)
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Oct 11, 2005 at 01:34:16PM +0200, Graham Leggett wrote:
> We provide SRPMs for building, which contain "fixed" httpd.spec files.
I see people downloading them a fair ammount ( > 400 per day, which is
actually quite a lot for the binaries section), and I don't see why
these would discontinue. So, would it be so bad a thing if the release
tarball wasn't itself buildable?
What is the number of commands it takes to turn an SRPM into a binary
.rpm ?
> Either that or the i386 builds work as is for people on i386 platforms. I
> personally deploy from a locally built SRPM, but that's me.
I deploy a locally built .deb, and that's much more work, so building
an rpm locally might be a lot more common than I suspect.
> Ideally the rpm builds should be continuously integrated using something
> like gump, so we catch the problem as it happens, rather than after
> release.
+1
> > I don't think having to un-tar a tarball, and mv a file in place is that
> > big an imposition on a packager.
>
> Anything that's non obvious or non standard is definitely an imposition on
> a packager. Don't make the packager do something that can be (and already
> is) easily automated :)
Well to be honest, I'm kind of confused as to why the source tarball
should be doing any of the packager's work, but I guess that's a
different argument :-)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Colm MacCarthaigh said:
> How many people actually build RPM's is what I'm wondering, given the
> errors that creep in in the releases, and we don't see that many
> complaints, it can't be a very high number. I see a fair amount of
> downloads for the RPM's files themselves, which is what makes me wonder.
We provide SRPMs for building, which contain "fixed" httpd.spec files.
Either that or the i386 builds work as is for people on i386 platforms. I
personally deploy from a locally built SRPM, but that's me.
Ideally the rpm builds should be continuously integrated using something
like gump, so we catch the problem as it happens, rather than after
release.
> I don't think having to un-tar a tarball, and mv a file in place is that
> big an imposition on a packager.
Anything that's non obvious or non standard is definitely an imposition on
a packager. Don't make the packager do something that can be (and already
is) easily automated :)
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Oct 11, 2005 at 11:38:03AM +0200, Graham Leggett wrote:
> Anybody who wants to run the latest version of httpd on their RPM based
> server,
How many people actually build RPM's is what I'm wondering, given the
errors that creep in in the releases, and we don't see that many
complaints, it can't be a very high number. I see a fair amount of
downloads for the RPM's files themselves, which is what makes me wonder.
I don't think having to un-tar a tarball, and mv a file in place is that
big an imposition on a packager. I mean I have to copy over an entire
"debian/" hierarchy and modify the Makefile before I install a new
version on our production kit, and I've considered that an imposition.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Colm MacCarthaigh wrote:
> Who cares if that works? How many people build their own RPM's from
> httpd source tarballs? (just wondering).
Anybody who wants to run the latest version of httpd on their RPM based
server, rather than the typically more conservative versions provided
for by native distributions.
httpd v2.1.x for example is available as both source and binary RPMs
from the ASF, I am not aware of any distro that supports httpd v2.1.x yet.
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Oct 11, 2005 at 11:22:12AM +0200, Graham Leggett wrote:
> The spec file needs to end up as "httpd.spec" in the root of the tarball
> so that "rpmbuild -tb httpd-2.0.55.tar.gz" works, so keeping it in a
> separate tree isn't going to work properly.
Who cares if that works? How many people build their own RPM's from
httpd source tarballs? (just wondering).
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Ondrej Sury said:
> Then I would suggest to provide _clean_ .tar.gz not including any .spec
> or whatever and *also* provide .src.rpm package for bleeding edge
> testers. How does it sound to you?
In other words a return to where we started way back when, ie no spec file
at all, and various vendors offering their own competing and incompatible
spec files.
I am not sure what problem you are trying to solve by removing the specfile?
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Ondrej Sury <on...@sury.org>.
On Thu, 2005-10-13 at 14:44 +0200, Graham Leggett wrote:
[...]
Sounds reasonable...
> Sometimes however, someone might need a bleeding edge feature not
> offered by a distro, but they might not want to clutter up their
> system
> with "custom" install trees. The ASF packages serve the needs of this
> group of people.
Then I would suggest to provide _clean_ .tar.gz not including any .spec
or whatever and *also* provide .src.rpm package for bleeding edge
testers. How does it sound to you?
Ondrej.
--
Ondrej Sury <on...@sury.org>
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Ondrej Sury wrote:
> Sorry, but in DEB world, this is pretty normal to have separate upstream
> source and debian/ subdirectory and it's not serious pain at all.
Exactly, it's normal in the debian world, but it's not normal in the rpm
world.
Each packaging system has it's own "default" way of handling packaging.
In the case of RPM, it's "rpmbuild --rebuild yyy.src.rpm", or "rpmbuild
-tb yyy.tar.gz". Debian does it differently, just like Solaris pkg does
it differently, but it makes no difference.
I have in the past wasted *hours* of time because the packager of an RPM
expected the user to "just know" that their package had some weird
custom process of producing an RPM, and when this was posted as a bug
the answer was "oh, you should have read the documentation".
I had read the documentation: the rpm man page, which clearly details
the --rebuild and -tX options.
With packaging, the needs of the users come first, the needs of the
packager comes second. Sure, it will be nice and neat for packagers to
have packaging scripts in a single archive, but that's a pain for the
end user.
> Upstream and packagers work in clearly separated and in my view it's
> good. But my view can be twisted since there are propably a bit
> different *standards* how is package provided in DEB and RPM world, ie.
> debianers are not used to compile packages themselves a lot, they use
> packages provided by their distribution.
Virtually all distros offer a somewhat conservative approach to
packaging - they are typically a few versions behind, and there are good
reasons for this.
Sometimes however, someone might need a bleeding edge feature not
offered by a distro, but they might not want to clutter up their system
with "custom" install trees. The ASF packages serve the needs of this
group of people.
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Ondrej Sury <on...@sury.org>.
On Wed, 2005-10-12 at 12:10 +0200, Graham Leggett wrote:
> William A. Rowe, Jr. said:
>
> > So... is it unreasonable in README.RPM to point the user to obtain the
> > current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz
> > which would be grabbed from svn httpd/package/rpm/, and drop it into the
> > unpacked httpd-2.0.55 source tarball, in order to package?
>
> Secondly the httpd.spec file contains version specific information (the
> version number, the MMN, etc) that would be both a serious pain to
> maintain separately by a packager and a serious pain to tie up with the
> required source by a person building an RPM.
Sorry, but in DEB world, this is pretty normal to have separate upstream
source and debian/ subdirectory and it's not serious pain at all.
Upstream and packagers work in clearly separated and in my view it's
good. But my view can be twisted since there are propably a bit
different *standards* how is package provided in DEB and RPM world, ie.
debianers are not used to compile packages themselves a lot, they use
packages provided by their distribution.
O.
P.S.: Please, keep it cool and don't flame.
--
Ondrej Sury <on...@sury.org>
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. said:
> So... is it unreasonable in README.RPM to point the user to obtain the
> current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz
> which would be grabbed from svn httpd/package/rpm/, and drop it into the
> unpacked httpd-2.0.55 source tarball, in order to package?
I would say yes for two reasons, firstly in the RPM world this is the norm:
rpmbuild -tb httpd-2.0.55.tar.gz
Introducing "special" build instructions means a lot of time wasted while
the user tries to figure out why the expected behaviour doesn't work.
Secondly the httpd.spec file contains version specific information (the
version number, the MMN, etc) that would be both a serious pain to
maintain separately by a packager and a serious pain to tie up with the
required source by a person building an RPM.
Both RPM and PKG are done with simple scripts, separating them from the
tarball turns a simple exercise into a complex one.
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> William A. Rowe, Jr. said:
>
>
>>The problem is that packaging is almost a 20/20 hindsite game. There's
>>no way we should expect that all of these many platform specifics can
>>all be maintained pre-release. That's why, in the Win32 .msi case,
>>there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32
>>packaging flavor. It doesn't get fixed for a specific release until
>>we know exactly what needed to be fixed :)
>>
>>I'm concerned that the current .spec solution is wrong; it's very
>>platform specific (platform meaning deployment mechanics, in this
>>case, I'm not slamming non-unix rpm implementations). Perhaps we
>>rejigger the tree to
>>
>> httpd/
>> package/
>> roll-release/
>> win32-msi/
>> rpm/
>> pkg/
>>
>>Thoughts?
>
> The spec file needs to end up as "httpd.spec" in the root of the tarball
> so that "rpmbuild -tb httpd-2.0.55.tar.gz" works, so keeping it in a
> separate tree isn't going to work properly.
>
> The problem remains though - people change stuff within the tree, which
> affects the packaging, and this only surfaces when a release is rolled.
So... is it unreasonable in README.RPM to point the user to obtain the
current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz
which would be grabbed from svn httpd/package/rpm/, and drop it into the
unpacked httpd-2.0.55 source tarball, in order to package?
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. said:
> The problem is that packaging is almost a 20/20 hindsite game. There's
> no way we should expect that all of these many platform specifics can
> all be maintained pre-release. That's why, in the Win32 .msi case,
> there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32
> packaging flavor. It doesn't get fixed for a specific release until
> we know exactly what needed to be fixed :)
>
> I'm concerned that the current .spec solution is wrong; it's very
> platform specific (platform meaning deployment mechanics, in this
> case, I'm not slamming non-unix rpm implementations). Perhaps we
> rejigger the tree to
>
> httpd/
> package/
> roll-release/
> win32-msi/
> rpm/
> pkg/
>
> Thoughts?
The spec file needs to end up as "httpd.spec" in the root of the tarball
so that "rpmbuild -tb httpd-2.0.55.tar.gz" works, so keeping it in a
separate tree isn't going to work properly.
The problem remains though - people change stuff within the tree, which
affects the packaging, and this only surfaces when a release is rolled.
> In the interim; is this a showstopper? Do we generally do the right
> thing (e.g. without changes, can we package up using the existing
> rpm files?) Obviously 2.0.54 was mispackaged as well, it's minimum
> apr package dependency should have been 0.9.6 apr, not 0.9.5.
It's not a showstopper no. In the mean time I have been producing SRPM
source archives that contain the original pristine httpd source, and a
"fixed" httpd.spec file. They are available from the binaries/rpm/SRPM
directory in the distribution directory.
Regards,
Graham
--
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Luc Pardon wrote:
>>Oden Eriksson wrote:
>>
>>>And some investigations told me it requires apr 0.9.7, maybe the autotools
>>>stuff should check for this or be documented?
>>
>>Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
>>announce, certainly, and on the downloads page README - would that
>>suffice?
>
> There seems to be a bug in the httpd.spec file.
>
> It says:
> Requires: apr >= 0.9.5, apr-util 0.9.5
> and the devel packages (on the httpd package specs) have no version
> number:
> BuildPrereq: apr-devel, apr-util-devel
>
> Also, the changelog section in the spec file does not show the upping
> to 2.0.55. The last documented chenge is for 2.0.53. And it says:
> "changed build to use external apr and apr-util".
>
> This confuses me, since apr seems to be present in the 2.0.53 and
> 2.0.55 tarballs ...
APR was also present in the 2.0.54 tarball.
This was a snafu in the way the rpm change was presented, not in the
tarballs. httpd-2.0's distribution tarball will always contain apr 0.9.
That doesn't mean httpd-2.2 (with apr 1.x) will do the same; that's yet
to be determined.
Coming back to rpm's for the moment; I do *not* mean to suggest that
this is the best solution for any specific platform or distribution
method, be it .rpm, .depot, .pkg, .msi, or any other facility.
The problem is that packaging is almost a 20/20 hindsite game. There's
no way we should expect that all of these many platform specifics can
all be maintained pre-release. That's why, in the Win32 .msi case,
there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32
packaging flavor. It doesn't get fixed for a specific release until
we know exactly what needed to be fixed :)
I'm concerned that the current .spec solution is wrong; it's very
platform specific (platform meaning deployment mechanics, in this
case, I'm not slamming non-unix rpm implementations). Perhaps we
rejigger the tree to
httpd/
package/
roll-release/
win32-msi/
rpm/
pkg/
Thoughts?
In the interim; is this a showstopper? Do we generally do the right
thing (e.g. without changes, can we package up using the existing
rpm files?) Obviously 2.0.54 was mispackaged as well, it's minimum
apr package dependency should have been 0.9.6 apr, not 0.9.5.
Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Luc Pardon <lu...@skopos.be>.
> Oden Eriksson wrote:
> >
> > And some investigations told me it requires apr 0.9.7, maybe the autotools
> > stuff should check for this or be documented?
>
> Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
> announce, certainly, and on the downloads page README - would that
> suffice?
>
There seems to be a bug in the httpd.spec file.
It says:
Requires: apr >= 0.9.5, apr-util 0.9.5
and the devel packages (on the httpd package specs) have no version
number:
BuildPrereq: apr-devel, apr-util-devel
Also, the changelog section in the spec file does not show the upping
to 2.0.55. The last documented chenge is for 2.0.53. And it says:
"changed build to use external apr and apr-util".
This confuses me, since apr seems to be present in the 2.0.53 and
2.0.55 tarballs ...
Sure enough, 2.0.55 compiles just fine using my old spec file (derived
from an old RedHat httpd 2.0.44 spec file). The resulting httpd rpm
package does contain libapr and libaprutil 0.9.7.
However, with the spec file from the tarball (with the apr
BuildPrereq's commented out to get it to confgure/make), I get compile
errors.
I plead guilty to not having followed the apr-related threads, but I'd
expect the RPM spec file to keep me out of trouble with any deps. IMHO,
it should rpmbuild right out of the box.
If somebody can get me updated on the status of apr (version, bundled
or not) and on what the spec file is trying to accomplish (e.g. separate
apr packages), I'd probably be able to fix it myself.
Luc Pardon
Skopos Consulting
Belgium
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Oden Eriksson wrote:
>
> And some investigations told me it requires apr 0.9.7, maybe the autotools
> stuff should check for this or be documented?
Yup - apr 0.9.7 is part of the bundle. We can spell this out in the
announce, certainly, and on the downloads page README - would that
suffice?
Re: [pre-release] 2.0.55 *candidate* available for testing
Posted by Oden Eriksson <oe...@mandriva.com>.
måndag 10 oktober 2005 06.42 skrev William A. Rowe, Jr.:
> The httpd-2.0.55 candidate, including win32 source .zip and installers*,
> is now available for testing at
>
> http://httpd.apache.org/dev/dist/
>
> Please review this candidate, and when responding, indicate the precise
> operating system that you have tested.
>
> Thank you for your assistance!
>
> Bill
>
> * note that win32 binary installers were uploaded only at this hour, and
> it will take up to another two hours for the public server to resync.
> Thanks for your patience.
I saw this:
Cannot load /etc/httpd/modules/mod_cgi.so into
server: /etc/httpd/modules/mod_cgi.so: undefined symbol:
apr_procattr_addrspace_set
And some investigations told me it requires apr 0.9.7, maybe the autotools
stuff should check for this or be documented?
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se