wo months would be good. However Apache foo is a *major* piece
of the planetary software ecosystem possibly more so than ISC software.
So a quarterly schedule ( 3 months ) may be more reasonable.
> Since I started thinking about it, I'm wondering whether we should push
> towards apr-util-1.7.0, or just get to apr-2.0.0 already. Other thoughts
> or observations?
Neither at this time.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
E="www/conf/mime.types"
-D SERVER_CONFIG_FILE="www/conf/httpd.conf"
beta $
What baffles me is the APR-UTIL 1.5.3 version seen above.
I am absolutely using 1.6.1 here.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
ting build/pkg/pkginfo
config.status: creating apr-1-config
config.status: creating apr.pc
config.status: creating test/Makefile
config.status: creating test/internal/Makefile
config.status: creating include/arch/unix/apr_private.h
config.status: executing libtool commands
libtoolT: No such file or directory
config.status: executing default commands
beta $
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On 09/15/2018 08:16 PM, William A Rowe Jr wrote:
No worries, thanks for all the follow up.
I am a little concerned that some 'fix' in a later ptf has changed poll
semantics in an undesirable way, but we will just be patient and wait
for word.
Again, TY,
Small annoying patch :
***
All tests passed.
Took a clean room to do it. If there are problems they are outside of
1.6.5 somewhere.
An entirely new instance with nothing interesting installed or running :
$ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
SPARC64-VII+ (portid 1024 impl 0x7 ver
Some process called "./testall -v" is running and also doing nothing.
Zero activity there. Truss says so.
# ps -ef | grep 29868
dclarke 29868 26961 0 19:48:54 pts/14 0:00 /usr/bin/bash -c
teststatus=0; \progfailed=""; \for prog in testlockperf test
root 5561 12826 0
On 09/14/2018 12:10 AM, William A Rowe Jr wrote:
Although 1.6.5 has flown, please do follow up with your observations.
This isn't going well. Two systems. Similar configs. Both are stuck in
testpoll test for a while now. Well over a half hour.
https://i.imgur.com/V6IHf9J.png
I will try a
On 09/11/2018 05:48 PM, Yann Ylavic wrote:
On Tue, Sep 11, 2018 at 11:33 PM Dennis Clarke wrote:
testsock: Line 376: Cannot test if connect completes
synchronously
This one really depends on the time taken by the system to connect
localhost non-blocking.
If it's immediate
On 09/11/2018 05:10 PM, William A Rowe Jr wrote:
On Tue, Sep 11, 2018 at 3:16 PM Dennis Clarke <mailto:dcla...@blastwave.org>> wrote:
The way to answer this question is to rebuild apr 1.6.3 (perhaps 1.6.0)
on this
specific machine to compare the results and ensure we haven't i
ake[1]: Leaving directory
'/usr/local/build/apr-1.6.5_SunOS5.10_sparc64vii+.001/test'
Dennis Clarke
On 08/24/2018 12:48 PM, Eric Covener wrote:
On Fri, Aug 24, 2018 at 12:37 PM Dennis Clarke wrote:
On 08/24/2018 09:16 AM, Eric Covener wrote:
Starting a new thread as potential RM's may be filtering bugzilla emails.
There are a lot of reports of PR62644 from solaris users of httpd, can
On 08/24/2018 09:16 AM, Eric Covener wrote:
Starting a new thread as potential RM's may be filtering bugzilla emails.
There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?
I am running a few versions of httpd on solaris and have not seen any
issues. Is there a
On 06/29/2018 03:57 PM, Duttera, Scott A CIV DISA SEL5 (US) wrote:
We are attempting to compile Apache 2.4 on a Unix system here, and got hit with
prereqs by the compiler for the APR libraries. When we downloaded the Unix
Source for the APR-util 1.6.1 and APR iconv 1.2.2 software from the
On 06/11/2017 05:37 PM, Nick Kew wrote:
On Fri, 9 Jun 2017 08:04:56 -0500
William A Rowe Jr wrote:
We've voted on this package a number of times, it probably
does have the votes if we search through these original two
vote threads, but just to be clear I'll spin a new
On 06/08/2017 10:56 AM, William A Rowe Jr wrote:
On Wed, Jun 7, 2017 at 9:44 PM, Dennis Clarke <dcla...@blastwave.org> wrote:
On 06/07/2017 08:16 PM, William A Rowe Jr wrote:
As I said... checking out and building 'your own tarball' on a
conventional system absolutely beats convinci
On 06/07/2017 08:16 PM, William A Rowe Jr wrote:
As I said... checking out and building 'your own tarball' on a
conventional system absolutely beats convincing AIX, Solaris
By "conventional" I think you mean "Linux" or anything with a reasonable
GNU toolchain and we all know that won't happen
On 06/07/2017 06:20 PM, William A Rowe Jr wrote:
https://github.com/apache/apr/tree/1.6.x?files=1 is our GitHub mirror of
the 1.6 branch.
Note you need to run ./buildconf - this requires libtool, autoconf and
python.
python? really? I need python to run buildconf?
uggg ... that is a
On 06/07/2017 03:28 PM, Nick Kew wrote:
On Tue, 6 Jun 2017 17:16:23 -0500
William A Rowe Jr wrote:
On Thu, Jun 1, 2017 at 4:11 PM, William A Rowe Jr
wrote:
On Wed, May 31, 2017 at 5:24 PM, William A Rowe Jr
wrote:
Greg and
On 05/30/2017 11:06 AM, Nick Kew wrote:
It's looking fine since Bill's surgical work last week.
I'm minded to T apr-1.6.1 tomorrow, and put it up
along with apr-util-1.6.0 for vote as Release Candidates.
Any objections?
Certainly none from me however I have yet to get my Apache 2.4.x
builds
r two before I'm
fit for any such thing.
Just before the great tarball release to the world mind if I have
another compile and test run with my C99 POSIX strict solaris compilers?
Dennis Clarke
ps: I assume there is a pre-release tarball hanging around
At the moment compile of httpd 2.4.25 stops very early with :
"/usr/local/include/apr-1/apr.h", line 614: #error: no decision has been
made on APR_PATH_MAX for your platform
So perhaps a quick define here would work.
[ self reply ]
Really we should get from limits.h :
99 #ifdef
: #error: no decision has been
made on APR_PATH_MAX for your platform
So perhaps a quick define here would work.
Dennis Clarke
Let us know if that makes a difference, perhaps a stale flavor of apr
is discovered first?
When in doubt look for the trivial first :-)
Loaded mysql driver OK.
Failed to open mysql[]
Loaded sqlite3 driver OK.
Opened sqlite3[] OK
create table
create table test successful
beta $ ldd -d ./dbd/.libs/apr_dbd_mysql-1.so
libmysqlclient.so.18 => /opt/mysql/mysql/lib/libmysqlclient.so.18
libsocket.so.1 =>/lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libm.so.2 => /lib/64/libm.so.2
librt.so.1 =>
So in another thread I have been going over this and over this and
finding little nits and getting past them and I do get a clean compile
but .. there are a few issues :
beta $ ldd -d ./dbd/.libs/apr_dbd_mysql-1.so
libmysqlclient.so.18 => /opt/mysql/mysql/lib/libmysqlclient.so.18
On 05/10/2017 01:37 PM, Nick Kew wrote:
On Wed, 10 May 2017 14:05:51 +0100
Nick Kew wrote:
But if you got through "configure" without it checking for expat,
you would seem to have found a bug.
Whoops! That should have read one or the other of expat
and libxml2, since those
On 05/10/2017 01:37 PM, Nick Kew wrote:
On Wed, 10 May 2017 14:05:51 +0100
Nick Kew wrote:
But if you got through "configure" without it checking for expat,
you would seem to have found a bug.
Whoops! That should have read one or the other of expat
and libxml2, since those
On 05/10/2017 01:37 PM, Nick Kew wrote:
On Wed, 10 May 2017 14:05:51 +0100
Nick Kew wrote:
But if you got through "configure" without it checking for expat,
you would seem to have found a bug.
Whoops! That should have read one or the other of expat
and libxml2, since those
On 05/10/2017 01:05 PM, Nick Kew wrote:
On Wed, 10 May 2017 11:33:13 +
Dennis Clarke <dcla...@blastwave.org> wrote:
So that seems to be gone from apr-1.6.0 and I hope expat-2.2.0 solves
the issue.
Yep, that's (due to be) part of the release notes.
But if you got through &quo
On 05/07/2017 08:37 PM, Yann Ylavic wrote:
On Sun, May 7, 2017 at 4:15 PM, Dennis Clarke <dcla...@blastwave.org> wrote:
node000 $ echo $CPPFLAGS
-I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
[]
During the compile is where
On 05/07/2017 08:37 PM, Yann Ylavic wrote:
On Sun, May 7, 2017 at 4:15 PM, Dennis Clarke <dcla...@blastwave.org> wrote:
node000 $ echo $CPPFLAGS
-I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
[]
During the compile is where
On 05/07/2017 12:28 PM, Nick Kew wrote:
On Sun, 7 May 2017 03:01:55 +
Dennis Clarke <dcla...@blastwave.org> wrote:
Where is this 1.6.0 tarball such that I may give it a careful build on
my Solaris servers ?
I don't see it at http://archive.apache.org/dist/apr/
http://apr.apache.o
On 05/07/2017 12:54 AM, William A Rowe Jr wrote:
So my blocking concern is that APR has never shipped an unready,
disabled by default feature. I don't mind not ready for prime time but
we traditionally called such things alpha or beta releases. I am not
worried about a specific platform, but
On 01/10/2017 01:12 PM, Rainer Jung wrote:
Hi Dennis,
Good day fine Sir.
Firstly, sorry for awaking what seems like a long dead cold bug but it
really isn't a "Large Files not supported" bug as opposed to just a
message that needs to be tweaked. Indeed yes this is a 64 bit build and
so
On 01/10/2017 12:57 PM, Yann Ylavic wrote:
On Tue, Jan 10, 2017 at 1:36 PM, Dennis Clarke <dcla...@blastwave.org> wrote:
re: https://bz.apache.org/bugzilla/show_bug.cgi?id=45615
re: long running (blocking?) apr_skiplist test.
I think we can close the bug about Large File Support an
re: https://bz.apache.org/bugzilla/show_bug.cgi?id=45615
I think it best to follow up here as per suggestions by Yann and Rainer
wherein I can run further tests and experiments to determine what is
happening here in these Niagara class systems.
Firstly, sorry for awaking what seems like a long
36 matches
Mail list logo