Re: Rev 8911: Honor 0x and 0 prefixes as numeric base indication when parsing squid.conf in http://squid-cache.org/bzr/squid3/trunk/
Is the following a sign that bundlebuggy is working in two locations now? Amos Alex Rousskov wrote: At http://squid-cache.org/bzr/squid3/trunk/ revno: 8911 revision-id:[EMAIL PROTECTED] parent: [EMAIL PROTECTED] committer: Alex Rousskov [EMAIL PROTECTED] branch nick: trunk timestamp: Wed 2008-04-02 22:41:41 -0600 message: Honor 0x and 0 prefixes as numeric base indication when parsing squid.conf integer options. Squid3 parses squid.conf file integers as decimal numbers while Squid2 honors 0 and 0x prefixes (indicating octal and hex numbers). The later functionality is needed for things like unmask that are traditionally specified using octal format. This patch changes Squid3 behavior to match that of Squid2. Internally, Squid3 uses sscanf and Squid2 uses strtol. TODO: Squid3::GetInteger should probably use xatol, and xatol should be fixed to proper verify the result of strtol. modified: src/Parsing.cc parsing.cc-20050103230824-8ncl0k4q72wd-1 === modified file 'src/Parsing.cc' --- a/src/Parsing.cc2007-08-13 23:20:50 + +++ b/src/Parsing.cc2008-04-03 04:41:41 + @@ -89,7 +89,8 @@ if (token == NULL) self_destruct(); -if (sscanf(token, %d, i) != 1) +// %i honors 0 and 0x prefixes, which are important for things like umask +if (sscanf(token, %i, i) != 1) self_destruct(); return i;
Re: monitoring bugzilla changes
On Wed, Apr 2, 2008 at 11:12 PM, Alex Rousskov [EMAIL PROTECTED] wrote: On Wed, 2008-04-02 at 22:19 +0200, Henrik Nordstrom wrote: 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 just subscribe squid-dev to bugzilla? It's squid-bugs which is the bug monitoring list.. Which is, apparently, requires more administration than the project can currently provide. It should not be that difficult for Amos or other developers to monitor bugs... I'm willing to step in and help with this kind of activities. If everyone agrees, I can start by working on restructuring and maintaining squid-related mailing lists. -- /kinkie
Re: bzr issues
On Thu, Apr 3, 2008 at 12:22 AM, Alex Rousskov [EMAIL PROTECTED] wrote: On Thu, 2008-04-03 at 08:55 +1100, Robert Collins wrote: On Wed, 2008-04-02 at 15:52 -0600, Alex Rousskov wrote: On Thu, 2008-04-03 at 08:38 +1100, Robert Collins wrote: On Wed, 2008-04-02 at 11:21 -0600, Alex Rousskov wrote: I think an incomplete [MERGE] default subject would be much better that the current behavior that will lead to _incorrect_ subjects. In addition, a command line option to specify the subject should be added. Amos wasn't entirely clear in his initial report. What is happening is that bzr send when there is no detected desktop mail client is providing a text editor window with *no* facility for setting the subject. This is clearly a usability bug, and once fixed the issue will go away. There is a bug open on this now. The second bug is that the default subject for desktop mail clients is wrong. You want just [MERGE] right ? This is something that bzr developers should decide. IMHO, [MERGE] or [MERGE] PUT SUBJECT HERE or even [MERGE] PUT SUBJECT HERE unique ID may work, I guess. The [MERGE] prefix seems to be needed because otherwise most folks will not know it is required for integration with other tools. However, if those tools differ in their requirements or often not used, then an empty subject is the best solution (some mailers will warn about it even). IMO integration with other tools should use out-of-band information, such as an extra mail header. [MERGE] in the subject is good to interact with humans, but too flimsy to be used with automated tools. -- /kinkie
Re: Rev 8911: Honor 0x and 0 prefixes as numeric base indication when parsing squid.conf in http://squid-cache.org/bzr/squid3/trunk/
On Thu, 2008-04-03 at 23:05 +1300, Amos Jeffries wrote: Is the following a sign that bundlebuggy is working in two locations now? 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 forwarded it. I am committing a lot of stuff to the eCAP branch and I did not want to spam the commit list with that... Cheers, Alex. Alex Rousskov wrote: At http://squid-cache.org/bzr/squid3/trunk/ revno: 8911 revision-id:[EMAIL PROTECTED] parent: [EMAIL PROTECTED] committer: Alex Rousskov [EMAIL PROTECTED] branch nick: trunk timestamp: Wed 2008-04-02 22:41:41 -0600 message: Honor 0x and 0 prefixes as numeric base indication when parsing squid.conf integer options. Squid3 parses squid.conf file integers as decimal numbers while Squid2 honors 0 and 0x prefixes (indicating octal and hex numbers). The later functionality is needed for things like unmask that are traditionally specified using octal format. This patch changes Squid3 behavior to match that of Squid2. Internally, Squid3 uses sscanf and Squid2 uses strtol. TODO: Squid3::GetInteger should probably use xatol, and xatol should be fixed to proper verify the result of strtol. modified: src/Parsing.cc parsing.cc-20050103230824-8ncl0k4q72wd-1 === modified file 'src/Parsing.cc' --- a/src/Parsing.cc2007-08-13 23:20:50 + +++ b/src/Parsing.cc2008-04-03 04:41:41 + @@ -89,7 +89,8 @@ if (token == NULL) self_destruct(); -if (sscanf(token, %d, i) != 1) +// %i honors 0 and 0x prefixes, which are important for things like umask +if (sscanf(token, %i, i) != 1) self_destruct(); return i;
Re: /bzr/squid3/trunk/ r8912: Attempted fix for FreeBSD run-time socket error (22) Invalid Object on connects
On Thu, 2008-04-03 at 21:39 +1200, Amos Jeffries wrote:
revno: 8912
committer: Amos Jeffries [EMAIL PROTECTED]
branch nick: trunk
timestamp: Thu 2008-04-03 21:39:06 +1200
message:
Attempted fix for FreeBSD run-time socket error (22) Invalid Object on
connects
This fix did not help.
Amos, do you have a FreeBSD system to test this on (squid-cache.org, for
example)? If not, it would be nice to undo all the changes that broke
FreeBSD connect because it is getting increasingly more difficult to
cherrypick which trunk commits to undo. I understand that you were
trying to fix a Linux leak but I think a completely broken connect on
FreeBSD trumps a leak on Linux, especially in trunk/.
FWIW, I have attached the relevant configure output with the latest fix.
I am not sure at all, but it feels like you are missing some #includes
in the test cases.
Thank you,
Alex.
configure:23105: checking for ss_len field in struct sockaddr_storage
configure:23135: gcc -c -Wall -g conftest.c 5
configure:23141: $? = 0
configure:23158: result: yes
configure:23174: checking for sin_len field in struct sockaddr_in
configure:23204: gcc -c -Wall -g conftest.c 5
conftest.c: In function `main':
conftest.c:52: error: storage size of 's' isn't known
conftest.c:52: warning: unused variable `s'
configure:23210: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME Squid Web Proxy
| #define PACKAGE_TARNAME squid
| #define PACKAGE_VERSION 3.HEAD-BZR
| #define PACKAGE_STRING Squid Web Proxy 3.HEAD-BZR
| #define PACKAGE_BUGREPORT http://www.squid-cache.org/bugs/;
| #define PACKAGE squid
| #define VERSION 3.HEAD-BZR
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_LIBDL 1
| #define HAVE_DLERROR 1
| #define CACHE_HTTP_PORT 3128
| #define CACHE_ICP_PORT 3130
| #define CONFIG_HOST_TYPE i386-unknown-freebsd5.5
| #define SQUID_CONFIGURE_OPTIONS '--prefix=/usr/local/squid3'
'--enable-icap-client' '--disable-optimizations'
| #define _SQUID_INLINE_
| #define USE_CARP 1
| #define USE_SQUID_ESI 0
| #define ICAP_CLIENT 1
| #define USE_WCCP 1
| #define USE_WCCPv2 1
| #define SQUID_SNMP 1
| #define USE_HTCP 1
| #define HTTP_VIOLATIONS 1
| #define USE_IDENT 1
| #define DISABLE_POOLS 0
| #define USE_UNLINKD 1
| #define USE_IPV6 0
| #define IPV6_SPECIAL_SPLITSTACK 0
| #define IPV6_SPECIAL_LOCALHOST 0
| #define IPV6_SPECIAL_V4MAPPING 0
| #define DNS_CNAME 0
| #define HAVE_SS_LEN_IN_SS 1
| /* end confdefs.h. */
|
| #include sys/types.h
| #include sys/socket.h
|
| int
| main ()
| {
| struct sockaddr_in s; s.sin_len = 1;
| ;
| return 0;
| }
configure:23227: result: no
configure:23243: checking for sin6_len field in struct sockaddr_in6
configure:23273: gcc -c -Wall -g conftest.c 5
conftest.c: In function `main':
conftest.c:53: error: storage size of 's' isn't known
conftest.c:53: warning: unused variable `s'
configure:23279: $? = 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME Squid Web Proxy
| #define PACKAGE_TARNAME squid
| #define PACKAGE_VERSION 3.HEAD-BZR
| #define PACKAGE_STRING Squid Web Proxy 3.HEAD-BZR
| #define PACKAGE_BUGREPORT http://www.squid-cache.org/bugs/;
| #define PACKAGE squid
| #define VERSION 3.HEAD-BZR
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_LIBDL 1
| #define HAVE_DLERROR 1
| #define CACHE_HTTP_PORT 3128
| #define CACHE_ICP_PORT 3130
| #define CONFIG_HOST_TYPE i386-unknown-freebsd5.5
| #define SQUID_CONFIGURE_OPTIONS '--prefix=/usr/local/squid3'
'--enable-icap-client' '--disable-optimizations'
| #define _SQUID_INLINE_
| #define USE_CARP 1
| #define USE_SQUID_ESI 0
| #define ICAP_CLIENT 1
| #define USE_WCCP 1
| #define USE_WCCPv2 1
| #define SQUID_SNMP 1
| #define USE_HTCP 1
| #define HTTP_VIOLATIONS 1
| #define USE_IDENT 1
| #define DISABLE_POOLS 0
| #define USE_UNLINKD 1
| #define USE_IPV6 0
| #define IPV6_SPECIAL_SPLITSTACK 0
| #define IPV6_SPECIAL_LOCALHOST 0
| #define IPV6_SPECIAL_V4MAPPING 0
| #define DNS_CNAME 0
| #define HAVE_SS_LEN_IN_SS 1
| #define HAVE_SIN_LEN_IN_SAI 0
| /* end confdefs.h. */
|
| #include sys/types.h
| #include sys/socket.h
|
| int
| main ()
| {
| struct sockaddr_in6 s; s.sin6_len = 1;
| ;
| return 0;
| }
configure:23296: result: no
Re: /bzr/squid3/trunk/ r8912: Attempted fix for FreeBSD run-time socket error (22) Invalid Object on connects
On Thu, 2008-04-03 at 08:56 -0600, Alex Rousskov wrote: I am not sure at all, but it feels like you are missing some #includes in the test cases. Adding #include netinet/in.h to test cases would give you: configure:23105: checking for ss_len field in struct sockaddr_storage configure:23159: result: yes configure:23175: checking for sin_len field in struct sockaddr_in configure:23229: result: yes configure:23245: checking for sin6_len field in struct sockaddr_in6 configure:23299: result: yes but the problem remains even with those fixed ./configure results: 2008/04/03 09:57:59.122| ConnectSateData::connect: to 10.0.0.104:1344 2008/04/03 09:57:59.122| comm_connect_addr: connecting socket 8 to 10.0.0.104:1344 (want family: 2) 2008/04/03 09:57:59.122| comm_connect_addr: sock=8, addrinfo( , family=2, addrlen=128 ) 2008/04/03 09:57:59.122| connect FD 8: (-1) (22) Invalid argument 2008/04/03 09:57:59.122| connecting to: 10.0.0.104:1344 2008/04/03 09:57:59.122| ConnectStateData::connect: FD 8: * - try again 2008/04/03 09:57:59.122| ConnectStateData::connect: FD 8: * - ERR tried too many times already. 2008/04/03 09:57:59.122| commConnectCallback: FD 8 HTH, Alex.
Re: /bzr/squid3/trunk/ r8912: Attempted fix for FreeBSD run-time socket error (22) Invalid Object on connects
Alex Rousskov wrote: On Thu, 2008-04-03 at 08:56 -0600, Alex Rousskov wrote: I am not sure at all, but it feels like you are missing some #includes in the test cases. Ah thanks for that. I've added it to configure. I've also rolled the specific comm_connect_addr parts out so trunk will run again until it can be tested more thoroughly. The rest is essentially unused code now but its unused code that needs to be tested and used. For Adrian and others doing Linux testing may want to use this patch to re-insert it: http://treenet.co.nz/prjects/squid/patches/linux-leak_comm_connect_addr.patch I'll see if one of the offers of FreeBSD test boxes are still open. I don't think I can or want to exactly run a live proxy on squid-cache.org itself. Amos Adding #include netinet/in.h to test cases would give you: configure:23105: checking for ss_len field in struct sockaddr_storage configure:23159: result: yes configure:23175: checking for sin_len field in struct sockaddr_in configure:23229: result: yes configure:23245: checking for sin6_len field in struct sockaddr_in6 configure:23299: result: yes but the problem remains even with those fixed ./configure results: 2008/04/03 09:57:59.122| ConnectSateData::connect: to 10.0.0.104:1344 2008/04/03 09:57:59.122| comm_connect_addr: connecting socket 8 to 10.0.0.104:1344 (want family: 2) 2008/04/03 09:57:59.122| comm_connect_addr: sock=8, addrinfo( , family=2, addrlen=128 ) 2008/04/03 09:57:59.122| connect FD 8: (-1) (22) Invalid argument 2008/04/03 09:57:59.122| connecting to: 10.0.0.104:1344 2008/04/03 09:57:59.122| ConnectStateData::connect: FD 8: * - try again 2008/04/03 09:57:59.122| ConnectStateData::connect: FD 8: * - ERR tried too many times already. 2008/04/03 09:57:59.122| commConnectCallback: FD 8 HTH, Alex. -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: bzr issues
On Thu, 2008-04-03 at 12:57 +0200, Kinkie wrote: IMO integration with other tools should use out-of-band information, such as an extra mail header. [MERGE] in the subject is good to interact with humans, but too flimsy to be used with automated tools. [MERGE] is used so humans can manually craft emails themselves. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
