Re: How to review a remote bzr branch
fre 2010-05-21 klockan 20:52 -0600 skrev Alex Rousskov: Pushed to launchpad: lp:~yadi/squid/cleanup-comm How can I review the changes as one patch without checking out your branch? Make sure you have an up to date copy of trunk, then from that run bzr diff -r ancestor:. --new lp:~yadi/squid/cleanup-comm but I recommend a checkout if you plan on reviewing the branch again later. It's fairly lightweight if using a shared repository with a lightweight checkout as I detailed in the Squid3VCS page. Regards Henrik
Re: How to review a remote bzr branch
What I do to review is usually 'bzr merge BRANCH'; bzr diff - and then eyeball. Thats roughly what a 'proposed merge' in launchpad will show too. You could do that as an alternative. -Rob
Re: Poll: Which bzr versions are you using?
What OS are you using? Upgrading to 2.0.x or newer would be advantageous. If there aren't packages for it, I'm sure we can figure out who to tickle to get some. -Rob
Re: Poll: Which bzr versions are you using?
fre 2010-05-21 klockan 20:39 -0600 skrev Alex Rousskov: On 05/19/2010 06:25 PM, Henrik Nordström wrote: For repository maintenance reasons I need to know which minimum bzr version all who work with the Squid repository need to be able to use. And I mean all, including those who do not have direct commit access. I.e the output of bzr --version | head -1 on the oldest platform you need or want to access the main bzr repository from. Bazaar (bzr) 1.3.1 Ugh.. what host is that? Is read access sufficient there, or do you also need commit access from that host? Regards Henrik
Re: /bzr/squid3/trunk/ r10490: Wrap extra IPv6 comm failover cases properly.
This was intentionally not wrapped in an ifdef as the code here is not IPv6 dependent. If anything it's actually IPv4 dependent... lör 2010-05-22 klockan 17:59 +1200 skrev Amos Jeffries: +#if USE_IPV6 /* Handle IPv6 over IPv4-only socket case. * this case must presently be handled here since the GetAddrInfo asserts on bad mappings. * NP: because commResetFD is private to ConnStateData we have to return an error and @@ -1244,6 +1245,7 @@ errno = ENETUNREACH; return COMM_ERR_PROTOCOL; } +#endif /* USE_IPV6 */ address.GetAddrInfo(AI, F-sock_family);
Re: Poll: Which bzr versions are you using?
On 05/22/2010 02:43 AM, Robert Collins wrote: What OS are you using? Upgrading to 2.0.x or newer would be advantageous. I have to use RHEL on that box: Linux dut 2.6.18-164.el5xen #1 SMP Tue Aug 18 15:59:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux If there aren't packages for it, I'm sure we can figure out who to tickle to get some. There was no newer package last time I checked but there is one available now. I will try to upgrade: Available Packages Name : bzr Arch : x86_64 Version: 2.1.1 Release: 3.el5 Alex.
Re: Poll: Which bzr versions are you using?
On 05/22/2010 10:49 AM, Alex Rousskov wrote: On 05/22/2010 02:43 AM, Robert Collins wrote: What OS are you using? Upgrading to 2.0.x or newer would be advantageous. I have to use RHEL on that box: Linux dut 2.6.18-164.el5xen #1 SMP Tue Aug 18 15:59:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux If there aren't packages for it, I'm sure we can figure out who to tickle to get some. There was no newer package last time I checked but there is one available now. I will try to upgrade: Available Packages Name : bzr Arch : x86_64 Version: 2.1.1 Release: 3.el5 That worked. I have at least 2.1.1 everywhere now. Thanks, Alex.
Re: [PATCH] TCP logging UDP Logging - Dhaval Varia
On 04/19/2010 03:26 AM, Amos Jeffries wrote: Kinkie wrote: On Thu, Apr 15, 2010 at 6:54 AM, Dhaval Varia dhavalkva...@gmail.com wrote: Dear Sir, Please find the attached patch file for the 1. TCP logging (Newly created) --- modtcp.patch The patch is not malformed now. I still don't understand the file-related error messages, so I leave this to someone with more clue than I do. Neither. They came in from ModUdp. I suspect they will never happen by have not felt keen to remove them as part of this change. 2. UDP logging (Modified) --- modudpfix.patch The test reversal seems fine. +1 (I don't understand why adding the four empty lines in logfile_mod_udp_open(); it clashes with Squid's coding style guidelines.) The needed 1-byte change to UDP has been in 3.HEAD for a while now. The UDP patch can be ignored now. would you please commit this TCP logging and UDP fix first?? I will see what to do to handle back pressure later. Ok by me. It's probably implicitly done if the socket is blocking. It's a regular comm_open TCP socket. So I think its non-blocking by default. Buffering is done by the module. But we neglected to increase the buffer size yet. I'm bumping it up to 64K on commit in a few minutes. As far as I could see the TCP logging code had no user-visible documentation and left most new types/functions undocumented as well, including the globally visible function. Please insist on documentation when accepting patches. Thank you, Alex.
Re: Open Source Software Forum
FYI. Original Message Subject:Open Source Software Forum Date: Thu, 13 May 2010 18:08:20 +0300 From: Mea OSS Team i...@meaossforum.com To: i...@squid-cache.org Dear Sirs We are organizing the first Open Source Software Forum in Egypt, we would like to invite you to cooperate with us in a way or another in our Open Source event,The issue is entirely new to the this part of the world and we plan to cover it in this regard. Please check the event website for further details www.meaossforum.com Thank you Best Regards Tamer Zaki
Re: DNS IPv6
On 05/14/2010 01:38 PM, Henrik Nordström wrote: As you may have noticed I have been looking at the IPv6 support in the last days, and now I am looking at how we perform DNS queries. Today we first do an query, followed by an A query. As we anyway do both queries it would be better if we ran both in parallell. The benefits of this is twofold: a) Lower latency. b) Easier policy on re-transmission But needs a bit of reshuffling to get done unfortunately, separating the actual queries a bit from the lookup. Is there an RFC or somesuch that recommends parallel lookups over sequential ones or vice versa? Thank you, Alex.
Re: [MERGE] Squid Patch (revision 10487)
On 05/19/2010 08:00 PM, Mark Nottingham wrote: Minor suggestions for the documentation: +NAME: access_sibling_when_stale +COMMENT: on|off +TYPE: onoff +DEFAULT: off +LOC: Config.onoff.access_sibling_for_stale_resource +DOC_START + By default, Squid will not contact siblings when it has + a stale cached response available. If on, siblings + that do not have the 'allow-miss' cache_peer option will + be queried even when there is a stale cached response. +DOC_END It is still not clear to an uninitiated reader whether this Squid or the sibling proxy has the stale response. it has and there is should be replaced with something more specific, IMHO. HTH, Alex.
