On 12/17/2009 04:06 PM, Leif Hedstrom wrote:
We do need to fix the following as well, preferably with this bug, but
I'm ok fixing it later:
./proxy/config/records.config.in:CONFIG proxy.config.admin.user_id
STRING nobody
./proxy/mgmt2/cop/TrafficCop.cc:static char admin_user[80] = nobody;
On 03/17/2010 05:58 PM, Leif Hedstrom wrote:
On 03/17/2010 10:27 AM, Mladen Turk wrote:
Also, I should point out this
http://incubator.apache.org/clutch.html
According to this, we have a check mark for every required item (as
far as I can tell).
Sure, that fine. However dunno if the board
On 03/18/2010 03:04 PM, Leif Hedstrom wrote:
On 03/18/2010 06:37 AM, Mladen Turk wrote:
On 03/18/2010 01:32 PM, Jim Jagielski wrote:
The only thing I think would be useful to discuss is the diversity
requirement...
Right, didn't found that info. Perhaps a company affiliation next
On 03/18/2010 03:35 PM, Leif Hedstrom wrote:
Can all the people who are no Yahoo's let me know which company
affiliation(s) they have? I had no idea we had to track what company
contributors / PMC members work for, that honestly seems a little bit
odd to me, but if it's the way, I'm fine with
On 03/18/2010 03:35 PM, Leif Hedstrom wrote:
Can all the people who are no Yahoo's let me know which company
affiliation(s) they have? I had no idea we had to track what company
contributors / PMC members work for, that honestly seems a little bit
odd to me, but if it's the way, I'm fine with
On 03/18/2010 04:11 PM, Leif Hedstrom wrote:
On 03/18/2010 09:04 AM, Mladen Turk wrote:
On 03/18/2010 03:35 PM, Leif Hedstrom wrote:
Can all the people who are no Yahoo's let me know which company
affiliation(s) they have? I had no idea we had to track what company
contributors / PMC members
On 03/29/2010 10:07 AM, jean-frederic clere wrote:
On 03/27/2010 03:47 AM, Leif Hedstrom wrote:
Also, did we get a final vote and decision on a PMC chair person?
According to Roy's comment on our we should go on with the graduation,
let's do it :-)
I'd still like to hear Jim's opinion
On 03/30/2010 04:03 PM, Jim Jagielski wrote:
On Mar 29, 2010, at 6:46 AM, Mladen Turk wrote:
On 03/29/2010 10:07 AM, jean-frederic clere wrote:
On 03/27/2010 03:47 AM, Leif Hedstrom wrote:
Also, did we get a final vote and decision on a PMC chair person?
According to Roy's comment on our
On 05/04/2010 06:20 AM, Leif Hedstrom wrote:
I need to know who wants access.
Count me in.
Seems that wiki works for all domains.
Regards
--
^TM
Hi,
According to the style guide and 'best practice'
there should be no trailing spaces in the code.
Any descent editor has 'Trim trailing spaces on save'
option and modifying editor preferences just for editing the
code could be a hassle, cause those formatting edits
could be intermixed with
On 05/09/2010 01:37 AM, Leif Hedstrom wrote:
I'd at least need the karma for assigning the issues (at least to me)
Done!
Thanks.
Regards
--
^TM
Hi,
Reusing is good, but I found out that one of the
very handy functions we could use (APR_LAYOUT/APR_ENABLE_LAYOUT)
has some hard-coded Apache Httpd dependency.
Namely the package prefix is hard-coded to 'apache2'
meaning it would need rewrite to be be usable.
Sure, we could modify that
Hi,
I have some plans to add the few handy build scripts
that would perfectly fit inside build directory (the usual place)
Also that would be the place for build/pkg/ and build/rpm/ as well.
Having that we could move the files from m4/ to that new
dir and instead
AC_CONFIG_AUX_DIR([build-aux])
On 05/12/2010 11:34 PM, Leif Hedstrom wrote:
Finally, I think Mladen wanted one more bug to get landed into trunk,
I'll defer to him and you on deciding if this should be landed or not.
We obviously want to avoid possibly breaking builds on various platforms
at this point, so if it lands, we'll
On 05/14/2010 06:59 PM, Leif Hedstrom wrote:
This ain't going to happen in 2.1.0
Not sure how promptly you guys expect 2.1.1
Release often, and early I think? I don't know what will go into 2.1.1,
but I have no problems doing a biweekly release (or simply as often as
necessary).
Sure, +1
On 05/14/2010 01:31 AM, John Plevyak wrote:
Tar ball updated with RAT, LICENSE, NOTICE changes.
Other bits identical.
Vote by Monday 8AM.
+1
Tested on RHEL5 32 bit.
RHEL5 x86_64 needs a LDFLAGS=-L/usr/lib64 during configure, but beside that
works fine.
Regards
--
^TM
On 05/15/2010 01:35 PM, Leif Hedstrom wrote:
Documentation says that
Note that the web interface is not being maintained.
Am I missing something obvious?
My personal preference would be to nuke all of the
GUI, and if someone is interested, we do a complete rewrite using modern
tools (Apache
On 05/19/2010 02:52 AM, John Plevyak wrote:
Why the hell uint64_t is defined this way and g++ complains even
though long int == long long it is beyond me.
Suggestions, comments?
I saw whole bunch of %ld, %lld stuff in the code which will IMHO
never be portable no matter what type you use.
On 05/19/2010 06:35 AM, John Plevyak wrote:
However, since the C99 and new C++ standard declares that long long int
is 64-bit and since just about everyone already has that:
linux, solaris, freebsd, mac, and since I have been able to use it
portably for several years now I would rather go that
On 05/19/2010 07:02 AM, John Plevyak wrote:
I would say that if we can't find a system which doesn't
support the standard %lld for 64-bit numbers then we should
just go with the standard. It is simpler and it will only
be more right as time passes because it is the standard.
Fair enough.
Hi,
I propose we remove all DIR_SEP code and just use the
slash directly.
The only reason for DIR_SEP can be windows, but I propose
that for windows we create a private set of
posix_path_to_windows_path_and_vice_versa set of functions
which would allow proper path construction
(eg, using \\?\
Hi,
We use stat all over the places for checking
the presence of the file or directory.
I propose we use access(path, R_OK [| W_OK]) instead,
since the check is done with the real user id.
Comments?
Regards
--
^TM
On 05/19/2010 08:25 AM, John Plevyak wrote:
I hate to say it, but the simplest thing is
to use long long int for all this junk. In practice
that is what it is on most systems, or at
least that covers their useful range.
Agreed.
Think that Leif is working on 64-bit file API, and
forcing that
On 05/25/2010 06:43 AM, Leif Hedstrom wrote:
E.g.
lib/trafficserver/remap.so
lib/trafficserver/blacklist-0.so
lib/trafficserver/replace-header.so
etc. Most of these are not intended for production use, and are fairly
unusable as is. I can see us building them as part of the build
process, but
On 05/25/2010 04:02 PM, Leif Hedstrom wrote:
That much said, there might be one or two plugins in the examples
directory that ought to get moved over to the official plugin
directory. I know Steve wrote a little Remap Plugin that I think could
be useful for users, and it is currently in the
On 05/25/2010 06:15 PM, Leif Hedstrom wrote:
On 05/25/2010 09:41 AM, Andrew Hsu wrote:
I'd be more inclined to see all the plugins moved into
http://svn.apache.org/repos/asf/trafficserver/plugins/
You mean including the examples? I'm really not that much in favour of
that, if we want to move
On 05/27/2010 06:35 PM, Alan M. Carroll wrote:
Thursday, May 27, 2010, 11:25:39 AM, you wrote:
Hi all,
Thoughts? I alread moved all remaining 2.1.0 bugs over to 2.1.1, since
v2.1.0 was released on 5/17.
I would like to get TS-338 put in 2.1.1 as there is already a patch
generated for it.
On 07/22/2010 12:09 AM, Manjesh Nilange wrote:
The attachments are missing (even though my sent folder email says the
attachments were part of it). I'm just going to copy-paste the two files
in the email.
Why don't create the JIRA issue (the usual way)
and attach the code in there.
I doubt
On 09/02/2010 07:00 PM, Leif Hedstrom wrote:
Hi all,
just a reminder (since this came up today), all Jira issues are emailed to a
mailing list
I got bunch of them. Again :)
Sorry, been a busy summer.
I'll got back to them this month.
Cheers
--
^TM
On 11/18/2010 01:09 PM, ming@gmail.com wrote:
hi, all:
per jMCg, it is a start even it is ugly, so here is our SPEC file for
trafficserver on redhat, it works for our half-production env.
http://zymlinux.net/trafficserver/rpm/
have some Chinese on the page, should not be a problem to
On 11/18/2010 02:52 PM, ming@gmail.com wrote:
that is one ugly thing, changed to Apache-2.0. :D
Excellent.
please aware that the layout config maybe need some tweak, please tell
me what your concern.
Can you please open a JIRA ticket and attach those
file clicking the needed
Instead hijacking thread ...
On 12/02/2011 06:17 PM, Leif Hedstrom wrote:
On 12/1/11 5:56 PM, Alan M. Carroll wrote:
I suppose I can get used to git (after all, I eventually moved on from RCS).
In exchange, you guys can get used to templates :-).
Eep, that seems like a steep price to pay ;)
Crap, I should have removed that email long time ago ;)
Original Message
To: trafficserver-...@incubator.apache.org
Instead hijacking thread ...
On 12/02/2011 06:17 PM, Leif Hedstrom wrote:
On 12/1/11 5:56 PM, Alan M. Carroll wrote:
I suppose I can get used to git (after
Thanks guys,
On 12/03/2011 06:19 PM, Alan M. Carroll wrote:
P.S. I've definitely found more than one bug in a compiler (both MSVC and g++)
from templates. I used to think that if I wasn't crashing the compiler with my
templates, I wasn't really trying. That's become a bit harder but I expect
On 12/04/2011 11:28 PM, Igor Galić wrote:
Hi folks,
This is primarily a bug fix release, but we also include a couple of new
features w.r.t. to SSL. For a full listing, see:
+1
Builds cleanly on RHEL6
Signature OK
Passes my set of tests.
Regards
--
^TM
On 09/19/2012 02:02 AM, Igor Galić wrote:
On Solaris this got me through the CPU affinity stuff, but hung on:
SplitDNS.cc, line 639: Error: Could not find a match for
ink_atomic_cas(SplitDNSConfigInfo**, SplitDNSConfigInfo*, SplitDNSConfigInfo*) needed in
On 09/20/2012 06:09 PM, Igor Galić wrote:
This saga has come to an End.
+1
With 97fd7b5..319d54 landed on master, we now support Sun Studio 5.9
through Solaris Studio 12.3 again.
That being said, I agree, that, unless the very unlikely happens and
Oracle gets their shit together and
On 09/21/2012 10:59 AM, Igor Galić wrote:
I also installed GCC 4.7 from OpenCSW repos.
Moving forward, I'd like to setup the trunk release and debug build
with GCC, while keeping a 3.2 release build with Solaris studio.
Sure, that's fine.
Just notice that we won't be able to redistribute
On 09/21/2012 11:14 AM, Igor Galić wrote:
Just notice that we won't be able to redistribute those binary
artefacts since they have OpenCSW library dependencies, but I
suppose we don't have intention to ship binaries anyhow.
With my OpenCSW Hat:
Are you member of OpenCSW team?
Regards
--
On 8.11.2018. 6:17, Leif Hedstrom wrote:
I've prepared a release for 7.1.5 (RC0), which is a bug fix release on the
previous v7.1.4 release. Besides regular bug fixes, this version also addresses
a number of small memory leaks. The release notes for 7.1.5 is available at:
On 21.11.2018. 1:00, Bryan Call wrote:
I've prepared a release for 8.0.1 (RC0). The release notes for 8.0.1 are
available at:
Make sure you refresh from a key server to get all relevant signatures. This
vote is open until EOB November 28th, but please test and cast your votes as
early as
41 matches
Mail list logo