sön 2008-04-06 klockan 10:55 -0600 skrev Alex Rousskov:
I would recommend backporting essential code changes only, if any. We
already had a few examples where innocent-looking backports broke
things, hurting users and delaying v3.1 work. Let's try to raise the bar
a little and see what
mån 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
Some comments...
There should be a general TPROXY define, shared
tis 2008-04-08 klockan 01:19 +0800 skrev Adrian Chadd:
There's stuff in Squid-3 (sslbump) for pulling apart the SSL stream.
That's for proxied request.
For transparen interception what you can do is to redirect the traffic
to an https_port using the transparent option. Works, but isn't really
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd:
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket
manipulation.
mån 2008-04-07 klockan 21:59 +0400 skrev HUB Netsky:
Good daytime, Henrik.
I am using squid-3-stable4 and generally satisfied with it.
But there is one problem. I need a request size to be logged. This
capeability was announced in the early log specification, but not
present at current
mån 2008-04-07 klockan 22:54 +0300 skrev Tsantilas Christos:
#4 0xb7c67060 in raise () from /lib/libc.so.6
#5 0xb7c68801 in abort () from /lib/libc.so.6
#6 0x0808f0a0 in xassert (msg=0x817ec96 index = 0,
file=0x817ec83 pconn.cc, line=89) at debug.cc:578
#7 0x080e5c96 in
mån 2008-04-07 klockan 22:54 +0300 skrev Tsantilas Christos:
It is a strange bug. I am able to reproduce it again and again only
while browsing wikipedia site and only if I have set the following debug
info:
debug_options 26,9 85,9 33,9 87,9 44,9
If I change something in this line the bug
mån 2008-04-07 klockan 22:21 +0200 skrev Henrik Nordstrom:
mån 2008-04-07 klockan 22:54 +0300 skrev Tsantilas Christos:
It is a strange bug. I am able to reproduce it again and again only
while browsing wikipedia site and only if I have set the following debug
info:
debug_options 26,9
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries:
But, baby steps people:
- Get it in
- Get it tested.
- Polish into a class.
So far we are at #1
And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the
code, even if it's just adding to the existing #if..
Get
, 2008, Henrik Nordstrom wrote:
I didn't test 2.6 today, but I know from earlier that it falls back
on
miss on large response headers.
Testing again to be sure and indeed it does. And not even a warning
in
cache.log about it..
Cute. Ok. Can we now release Squid-2.7
tis 2008-04-08 klockan 01:15 +0300 skrev Tsantilas Christos:
Looks possible that it is an AsyncCalls bug, but must not happen. I can
not understand it...
It is. Just did a 100% reproducible testcase for it using gdb.
1. Start a new request and identify it's outgoing filedescriptor
mån 2008-04-07 klockan 17:32 -0400 skrev [EMAIL PROTECTED]:
I tried redirecting to a local https_port on the same daemon as http_port, but
it wouldn't even listen on the socket I configured.
Perhaps I should try harder..
Yes...
https_port 4433 cert=/path/to/proxy_cert.pem
This is a resubmission of the 3.0 patch for Bug #2001. This time
including the related fix for reply_header_max_size making it check the
limit while reading the header and not after..
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: [EMAIL PROTECTED]
# djj9wfqy63noyuy4
#
The following is the list of patches I think should get backported to
3.0:
- The fix for Bug #2001 after it's been verified proper with ICAP and
large responses.. Backport mailed to squid-dev and in my bzr repository.
Seems to pass all tests fine.
- Removed execute bit from various
mån 2008-04-07 klockan 16:52 +0800 skrev Adrian Chadd:
Cute. Ok. Can we now release Squid-2.7 ? :)
I think so.
But I'd like to get a final 2.6 release out the door first, rolling up
the latest patches.
However, 2.7 (and 3.0) quite likely breaks shoutcast, a non-HTTP
protocol on port 80 using
sön 2008-04-06 klockan 08:33 -0600 skrev Alex Rousskov:
Why do we only clone replies and not requests? Can a request have a
large header? Do we already deal with that without cloning?
Requests is already referenced and cloned if needed only, and has been
since many years back.
For requests we
sön 2008-04-06 klockan 16:48 +0200 skrev Guido Serassio:
My needs are:
- A Windows specific development/stable branch based on the STABLE
branch, so, now there is
Which I question, but we had that discussion already.
SQUID_NT_3_0 based on SQUID_3_0, likely in the future will be
sön 2008-04-06 klockan 08:50 -0600 skrev Alex Rousskov:
bb:comment
Have you tested this with an ICAP server enabled?
No. My ICAP setup is quite limited.
Regards
Henrik
sön 2008-04-06 klockan 18:44 +0200 skrev Guido Serassio:
If I'm not wrong, the needed steps are listed in the Merge another
branch into yours section.
The SOURCE_OF_FOO branch must be already locally checked-out, right ?
Not unless you want to.. but if you follow the instructions it will be.
sön 2008-04-06 klockan 10:48 -0600 skrev Alex Rousskov:
Placing a _temporary_ hold until I (or somebody) tests this with ICAP.
If nobody can, I should be able to in a couple of days. We had quite a
few bugs in 3.0 because of things being backported so let's try to be a
little bit more careful
sön 2008-04-06 klockan 20:00 +0300 skrev Tsantilas Christos:
I will do some tests.
Henrik are you still using the bzr tree here:
http://www.henriknordstrom.net/bzr/squid3/hno/largeresp/
Yes. It's up to date. And so is the largeresp-3.0 branch at the same
location with the 3.0 backport.
bzr
mån 2008-04-07 klockan 01:07 +0800 skrev Adrian Chadd:
As discussed on IRC, I'm not sure where in 2.5/2.6 the response status/headers
are allowed to grow past 4k _AND_ be parsed.
From what it seems it's not...
2.7 (and 3 with the submitted patch) behaves better there.. only having
problems on
sön 2008-04-06 klockan 18:15 +0200 skrev Guido Serassio:
Try
bzr+ssh://[EMAIL PROTECTED]/repo/branch
Yes, it works.
I think that this should be in http://wiki.squid-cache.org/Squid3VCS.
Agreed.
The whoami bzr command could be a little confusing about this.
I see how one comes to that
sön 2008-04-06 klockan 00:45 +1300 skrev Amos Jeffries:
The ./html/ folder generated does not get emptied between runs. So if
the code has changed, we may get new or dead files, and every time the
graphs are reproduced with new hashes they cause dead files.
Such things are supposed to get
tor 2008-04-03 klockan 10:43 +1100 skrev Benno Rice:
Some of you may remember me from the original https accelerator
support code way back when. I'm looking to get back into doing some
squid work in various areas and so thought getting back on to the dev
list would be a good idea. =)
lör 2008-04-05 klockan 15:05 +0800 skrev Adrian Chadd:
One of my contracts is to improve dataflow and reduce copying in Squid-2.
I've got one major bug in Squid-2.HEAD / Squid-2.7 to fix (4k response
headers for disk objects) which will probably be fixed as part of this
work.
Ok.
It would
Updated 3.0 patch. Had forgot to merge one related changeset from trunk
adding MemBuf::size(size).
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: [EMAIL PROTECTED]
# 00au6rconzwzcbdv
# target_branch: file:///data/bzr/squid3/branches/SQUID_3_0/
# testament_sha1:
Resubmissions as I haven't received any comments on the previous merge
request.
This patch fixes Bug #2001 by reworking how the client_side_*.cc code
deals with response headers. Instead of parsing the headers again it
clones the already parsed header and blindly skips the unparsed headers
in the
tor 2008-04-03 klockan 08:24 -0600 skrev Alex Rousskov:
The following is the message I had to manually forward to the commit
list because I have not yet learned how to configure bzr to
automatically pick sendto addresses based on the branch. The trunk
commit message was sent to me and I
ons 2008-04-02 klockan 18:44 +1300 skrev Amos Jeffries:
Henrik, there is still a problem in the ./update script.
Yes, that's because I didn't have time to finish it until today..
Regards
Henrik
ons 2008-04-02 klockan 21:47 +1300 skrev Amos Jeffries:
Henrik, I'm a little confused as to what you are trying to do here:
http://www.squid-cache.org/Versions/v3/HEAD/changesets/b8885.patch
The Makefile did everything to build both the html and the dyn properly.
How else were you
ons 2008-04-02 klockan 10:51 -0600 skrev Alex Rousskov:
I doubt bzr managed to generate a proper bundle, even though I did
follow instructions and did _not_ commit before running the two commands
below.
You need to commit on a branch before send.
send is for submitting the contents of a
ons 2008-04-02 klockan 11:00 -0600 skrev Alex Rousskov:
On Wed, 2008-04-02 at 13:04 +1300, Amos Jeffries wrote:
I only saw 2288 because it was mentioned in squid-users. Has my
subscribe to the bugzilla notify list gone astray again? I was getting
it for a few days, then nothing.
Can we
ons 2008-04-02 klockan 21:16 +0200 skrev Henrik Nordstrom:
ons 2008-04-02 klockan 10:51 -0600 skrev Alex Rousskov:
I doubt bzr managed to generate a proper bundle, even though I did
follow instructions and did _not_ commit before running the two commands
below.
You need to commit
ons 2008-04-02 klockan 14:59 -0600 skrev Alex Rousskov:
Do I still start the subject with [MERGE] to enable bb voting/approval
process?
If I understand the code correctly it picks up all messages having with
a subject of [MERGE* or [PATCH* as merge requests, even if there is no
patch.. and
ons 2008-04-02 klockan 15:12 -0600 skrev Alex Rousskov:
I may be missing something(*), but I think it would be better if
squid-dev was subscribed to bugzilla OR squid-bugs allowed folks to add
and remove themselves (but not post). The former will make discussing
bugs easier, but will move
tor 2008-04-03 klockan 08:55 +1100 skrev Robert Collins:
You want just [MERGE] right ?
Yes, or at least make it skip changesets which is already on the target
branch (i.e. merged from the target) when selecting the subject to use..
Having it pick a subject based on what is a merge from the
tis 2008-04-01 klockan 13:22 +1300 skrev Amos Jeffries:
Hmm. I debugged my way through that script and fixed a few things after I
last posted. I think I have it working now. The last commit should have
included my changes to make it create the tag and use the tag properly.
The script should
tis 2008-04-01 klockan 15:13 +1300 skrev Amos Jeffries:
So whats with the branch SQUID_NT_3_0 already in bzr? as shown here:
http://www.squid-cache.org/bzrview/
It's the import of the SQUID_NT_3_0 branch from CVS. But CVS do not have
the same merge details as bzr so the import doesn't know
tis 2008-04-01 klockan 10:49 +0530 skrev Prasad J Pandit:
I'm using Squid Cache: Version 3.0.STABLE1 for quite some time now, and am
happy to inform you that it's been doing really well.
The only recurring problem is that, it crashes leaving behind a
`var/cache/state.new' file of size
tis 2008-04-01 klockan 17:24 +0800 skrev Adrian Chadd:
Wait a sec, which platforms don't have sin_len in which struct?
I think amos meant to say ss_len in struct sockaddr_storage, which not
very frequently seen as not all address families need a length.. (for
example on Linux)
I do not know of
tis 2008-04-01 klockan 23:34 +1300 skrev Amos Jeffries:
The fix will be in tomorrows daily snapshot.
I'm also repeating my pre-commit test cycle to see if I can figure how
this got through in the first place.
I propose we withdraw 3.0.STABLE3, and release 3.0.STABLE4 shortly with
this fix
tis 2008-04-01 klockan 23:41 +1300 skrev Amos Jeffries:
As a maintainer, seeing STABLE3 not yet announced.
It's released the minute it's published.
Do you think, bug 2288 is one of these situations where we should bump a
stable4 out immediately?
Well.. with STABLE3 not compiling it's a
tis 2008-04-01 klockan 22:59 +1300 skrev Amos Jeffries:
I started out that way (assuming ss_len was absent but sin_len was
present) but a header analysis proved the assumption wrong. sin_len also
proves very absent from Debian Linux 2.6.25 headers.
Somehow I doubt that linux would change the
ons 2008-04-02 klockan 01:27 +1300 skrev Amos Jeffries:
That back-port is non-critical right? It's been broken for months.
More like days.. it was one of the patches you merged into Squid-3.0
just before 3.0.STABLE3...
So it
can wait a few days/weeks in the snapshots for some further testing
ons 2008-04-02 klockan 01:12 +1300 skrev Amos Jeffries:
3 had the fix for major regression bug 2206 (407 ProxyAuth header missing).
Ah, right..
Regards
Henrik
tis 2008-04-01 klockan 21:31 +0800 skrev Adrian Chadd:
G'day,
I believe this phase of the delay pools ACL and statistics work is ready
for commit to Squid-2. I've shuffled around the configuration file changes
a bit and used PRIu64 for printf().
ons 2008-04-02 klockan 00:38 +1300 skrev Amos Jeffries:
rio:/usr/include# grep -R sin_len ./*
Right.. I wonder where I was looking. Can't find it again today.
Regards
Henrik
ons 2008-04-02 klockan 07:22 +0800 skrev Adrian Chadd:
Try http://www.creative.net.au/diffs/s2_delaywork.diff .
Looks better.
No comments. Looks ready to merge.
Regards
Henrik
The autotool derived files have now been removed from trunk to avoid the
bootstrap mess when making changes needing a bootstrap.
On the down side this means you need to have a working autotool chain to
build trunk, and may need to remember to bootstrap your sources every
now and then..
Regards
The squid-3 3.0 changeset browsers has now been fully adopted to use
bzr as source.
The tags for SQUID_3_0 has also been imported as bzr tags instead of
branches.
Regards
Henri
ons 2008-04-02 klockan 13:04 +1300 skrev Amos Jeffries:
That is really weird. I have a local cbranch+bind of SQUID_3_0 in my
account folder for the release prep and bootstrap. Thats where I added
the tag and have committed since adding the STABLE3 one.
I don't see any STABLE1 or STABLE2
tor 2008-03-27 klockan 08:40 +0100 skrev Micalizzi Filippo:
I've dowloaded your patch in order to get working the acl in squid as
parent proxy with Dansguardian, but this patch doesn't work with any
version of 2.6..Is it possibile to get a new updateted one working on
2.6-Stable14 ?
The
sön 2008-03-30 klockan 16:37 -0600 skrev Alex Rousskov:
My understanding is that no CVS branches other than trunk and
squid3-ecap have been ported or moved to bzr. The decision to move is up
to the branch maintainer.
Everything in the main squid3 CVS repository has been migrated to bzr,
tis 2008-04-01 klockan 00:18 +1300 skrev Amos Jeffries:
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
+1
Regards
Henrik
mån 2008-03-31 klockan 08:26 -0600 skrev Alex Rousskov:
We may be able to provide better comments when we see the current code.
It does not have to be polished and ready for commit.
I see no reason to continue supporting now obsolete and no longer
supported TPROXY versions in new versions of
mån 2008-03-31 klockan 00:11 +0800 skrev Adrian Chadd:
I'll commit this work to 2.HEAD, 2.7 and 2.6 in a week or so.
2.HEAD ok. as always for anything reasonably sane in shape.
2.7 not sure. Would delay 2.7.STABLE even further.
2.6 no, feature frozen.
Regards
Henrik
mån 2008-03-31 klockan 18:40 +1300 skrev Amos Jeffries:
bzr: ERROR: Not a branch: /bzr/squid3/tags/SQUID_3_0_STABLE3/.
Have you created the tags/SQUID_3_0_STABLE3 release tag in bzr? Can't
find any SQUID_3_0_STABLE3 tag, neither in tags or branches..
Regards
Henrik
mån 2008-03-31 klockan 13:31 -0600 skrev Alex Rousskov:
What about Adrian plans (if I understood them correctly) to add
TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a
good enough reason to continue supporting unsupported TPROXY versions?
FreeBSD and TPROXY4 uses pretty
tis 2008-04-01 klockan 09:23 +1100 skrev Robert Collins:
On Mon, 2008-03-31 at 20:43 +0200, Henrik Nordstrom wrote:
But I have to ask Robert how we best continue the merge process on
that
branch.. I suspect it would actually be best to recreate the branch as
a
new bzr branch from
This patch makes Squid deal with responses having more than 4KB of
responseline + headers.
- Make the HTTP protocol handler continue reading the response until all
is received. This involves growing the header buffer as needed until the
header fits (or limit reached). Previously the buffer based
On Thu, 2008-03-27 at 22:26 -0400, Tres Seaver wrote:
OK. I had the impression that bzr's model was branch happy (compared
to CVS / SVN), which would seem to me to make forward porting more
attractive.
bzr is branch happy, and we use that quite extensively to cater new
developments and
Robert,
do you have any advice on how to best keep track of what to backport to
earlier (i.e. STABLE) releases?
With the CVS changeset wrappers we had external classification and
grouping of the changesets, making it quite easy to keep track of the
backporting status of each changeset using
On Fri, 2008-03-28 at 09:33 +1100, Robert Collins wrote:
So, for changeset id, I suggest we use the revision id of the commit
of
a change to trunk.
How do I get a parseable log with revision id's?
I know how to get the revno, but not revid..
but revno is good enough..
bzr doesn't yet,
On Wed, 2008-03-26 at 10:14 +1300, Amos Jeffries wrote:
Henrik Nordstrom wrote:
Revision 8905:
src/comm.cc: In function 'int comm_connect_addr(int, const IPAddress)':
src/comm.cc:1144: warning: passing NULL to non-pointer argument 2 of
'void* memset(void*, int, size_t)'
make[1
On Tue, 2008-03-25 at 17:18 -0600, Alex Rousskov wrote:
I already deleted generated files from the eCAP branch because I thought
somebody said we should all do it (and I hate how they spoil diffs) :-).
It's been discussed, and I have proposed doing it next week unless
someone objects.
I'll
On Wed, 2008-03-26 at 10:15 +1100, Robert Collins wrote:
The conflict resolver for revert uses a big hammer to make the tree
identical; in the case of local edits the merge above will conflict
and
keep your edit, the revert above will discard it.
'revert' is 'become'
'merge' is 'apply
On Wed, 2008-03-26 at 11:09 +1300, Amos Jeffries wrote:
I think its probably time we added aufs as one of the available default
filesystems.
On Linux yes, not sure about in general due to the depencendy on kernel
POSIX threads...
It's a pity POSIX AIO doesn't include open/close. If it did we
On Tue, 2008-03-25 at 09:09 -0600, Alex Rousskov wrote:
That's a good idea! The level can also change depending on the caller
(e.g., use eCAP level if eCAP code is calling the shared code).
Yes, ideally there would be a transaction state tied to the debug,
allowing expressions like comm I/O on
On Tue, 2008-03-25 at 10:23 +1300, Amos Jeffries wrote:
I found that in 3.x as well. It turns out those bits of valgrind code
only occur if both --enable-leakfinder and --with-valgrind-debug are
enabled.
My test script only had --with-valgrind which wasn't doing even the
job it needed
On Tue, 2008-03-25 at 10:34 +1300, Amos Jeffries wrote:
Robert Henrik,
Some of us have found a knowledge-hole in the bzr revert process.
We can easily reverse a patch using for example:
bzr revert -r 8902
I prefer using merge.
bzr merge -r 8903..8902
to undo revision 8903.
that
On Tue, 2008-03-25 at 11:29 +1300, Amos Jeffries wrote:
I missed that email from you.
I don't see any huge problems with that approach, as long as we make
sure its kept to.
Same here, except for some minor human confusion about which file is
really meant when someone says just file.h.
On Mon, 2008-03-24 at 22:14 -0600, Alex Rousskov wrote:
Should I use the same debugging sections for ICAP, eCAP, and the
code they share? Or should we have three distinct debugging sections for
those three areas?
I think using the same is appropriate, unless you think there will be a
need
On Tue, 2008-03-25 at 12:04 +1100, Robert Collins wrote:
'bzr revert' changes the working tree to be the same as a given revision
[with optional file list].
If you then do a commit - e.g:
bzr revert -r X
bzr commit
you are committing a changeset that happens to alter previously done
work,
bb:comment
patch looks very empty..
On Tue, 2008-03-25 at 13:13 +1200, Amos Jeffries wrote:
Replace a URN handling set of gotos' with a sub-function.
On Tue, 2008-03-25 at 12:23 +1100, Robert Collins wrote:
Is it valgrind being wrong, or does epoll actually read from that
unitinitialised region?
it's valgrind not knowing (or caring about) the full details of when
epoll uses what of the supplied data.
But generally speaking it's a good
Robert?
Should I go ahead and set up the needed accounts?
On Mon, 2008-03-24 at 14:33 -0600, Alex Rousskov wrote:
On Mon, 2008-03-24 at 14:30 -0600, Bundle Buggy wrote:
Submitter Alex Rousskov [EMAIL PROTECTED] does not
have voting rights
Nope.
Alex.
On Fri, 2008-03-21 at 14:33 +1300, Amos Jeffries wrote:
I've been thinking it would be a good idea to add the patch-cleaning
script to the source for people to use for submission. There are a few
minor issues to work out still but if you all agree I'll drop it in.
Is this the script we
On Wed, 2008-03-26 at 01:45 +1300, Amos Jeffries wrote:
My current version:
Cleans the ~N~ files created during merge.
Why? There may be important backups there from earlier reverts run by
the user..
Cleans the automake files out of the submitted patch
Ok I think, but complex and not
On Tue, 2008-03-25 at 21:21 +0900, Adrian Chadd wrote:
Is there any way to get this stuff to post an actual diff rather than
this bundle?
It's there.
But I think something was wrong with amos submission. Looks very empty
with a 0 lines patch and very small bundle..
Regards
Revision 8905:
src/comm.cc: In function 'int comm_connect_addr(int, const IPAddress)':
src/comm.cc:1144: warning: passing NULL to non-pointer argument 2 of
'void* memset(void*, int, size_t)'
make[1]: *** [comm.lo] Error 1
On Sun, 2008-03-23 at 18:29 +0900, Adrian Chadd wrote:
The real solution is a tree for offset lookups, and a linear walk of order
O(1) for subsequent sequential accesses.
Walking a tree is usually a cheap operation, unless the tree is wrongly
designed. You just need to remember the current
On Mon, 2008-03-24 at 00:16 +1300, Amos Jeffries wrote:
I care about every potential cause of trouble in squid. Particularly
avoidable ones that pop up all the time. 'Zero errors' policy and all that.
It may be that this is fixable by setting the first byte of the buffer
to '\0'. I'm just
On Sun, 2008-03-23 at 23:20 +1200, Amos Jeffries wrote:
Fix memory leak in Linux builds.
bb:approve
bb:approve
On Mon, 2008-03-24 at 00:03 +1200, Amos Jeffries wrote:
Replace a goto with do-while.
On Fri, 2008-03-21 at 15:35 +1300, Amos Jeffries wrote:
While we are at it what about the text and links following the releases
table.
* The Pending bugs link might be useful for 2.x.
Maybe. We had that for 2.5, but I never found that link to give any
really meaningful results. But we
On Fri, 2008-03-21 at 10:08 -0400, Matt Benjamin wrote:
Today, just request-side handling of Cache-Control: max-stale=0
(HttpHdrCc.c, 2.6-STABLE7+).
If request's Cache-Control: max-stale has any positive value, Squid
passes it through. Shouldn't the allowed range include 0 (delta-seconds
On Fri, 2008-03-21 at 18:16 -0400, Matt Benjamin wrote:
3. The current code is problematic because the spec has max-stale
without a value equivalent to max-stale: (Infinity)
Oh, I thought it didn't forward max-stale=0 at all.
Forwarding it as max-stale without a delta is defenitely a bug. The
On Fri, 2008-03-21 at 23:33 +0100, Henrik Nordstrom wrote:
On Fri, 2008-03-21 at 18:16 -0400, Matt Benjamin wrote:
3. The current code is problematic because the spec has max-stale
without a value equivalent to max-stale: (Infinity)
Oh, I thought it didn't forward max-stale=0 at all
On Thu, 2008-03-20 at 07:59 -0600, Alex Rousskov wrote:
Please also add wiki instructions on how such accounts should be added.
It's pretty easy, but should probably wait until Bundlebuggy is properly
installed. Currently in roberts home..
And if I get time I hope to look into making a
On Thu, 2008-03-20 at 09:20 -0600, Alex Rousskov wrote:
Hello,
Should we remove Obsolete releases from
http://www.squid-cache.org/Versions/v3/3.0/ which looks scary enough
without them?
Should say Older, not Obsolete..
It's only PRE releases, which by definiton is obsolete when the
At the sprint the issue about our current 10ms main loop timeout came
up, and it was suggested the problem most likely have been fixed in
HEAD. And even if it hasn't been fixed it's something which should be
fixed rather than plastered over by spinning around on a short timeout
when there is no
On Wed, 2008-03-19 at 22:39 -0600, Alex Rousskov wrote:
I need to go over that code once again, especially if 1 second change
breaks things again. I am for your change to HEAD because it might
expose the unresolved bug and prompt me to polish that code
further :-).
Thats the idea ;-)
On Thu, 2008-03-20 at 16:34 +1100, Robert Collins wrote:
Restarted loggerhead and it is working.
Thanks
On Tue, 2008-03-18 at 09:57 +0100, Kinkie wrote:
The idea is nice, but a bit dangerous IMO, as it lends itself to
abuse. I second that we can try it out, and see how it works out.
I think it will work out well. And in any case there is a second level
human filter to make the actual commit.
On Wed, 2008-03-19 at 11:15 +1300, Amos Jeffries wrote:
- I'm kind of in favour of it as a pure file-movements-only
alteration. 3.2 has no feature-requests yet and back-porting across a
file-re-arranged setup is likely to be more trouble than its worth.
bzr tracks renames and merges
On Sun, 2008-03-16 at 21:54 -0600, Alex Rousskov wrote:
On Sun, 2008-03-16 at 02:55 +0100, Henrik Nordstrom wrote:
Cons:
- Not entirely sure how ICAP and ESI fits into the reply processing. But
I hope there is no problem..
The bzr branch can be found at
http
On Mon, 2008-03-17 at 11:00 +0900, Adrian Chadd wrote:
It'll also answer the question of is it worth having a slab allocator in
2008.
My gut feeling says yes, but only for very small allocations.
And my gut feeling is no, as there is better ways to manage memory which
stresses the allocator
On Sun, 2008-03-16 at 22:01 -0600, Alex Rousskov wrote:
Should not these formatting changes wait for the global astyle+wrapper
application, to minimize the number of times folks need to resolve
conflicts in their branches?
I think it's better to get this cleaned up soon, before there is too
Robert, can you fix the bundlebuggy bug links to point to our bugzilla
instead of launchpad?
/bugs/show_bug.cgi?id=id
From what it looks this is set in bundlebuggy/templates/master.kid where
it's currently hardcoded to use the launchpad bug tracker.
Regards
Henrik
601 - 700 of 2137 matches
Mail list logo
