Re: IPv6 support and Windows
Hi Amos, At 05.06 17/08/2007, Amos Jeffries wrote: I have just imported and properly wrapped the libesmtp getaddrinfo and supporting implementation from fetchmail 6.3.8. I have done some simple configure and compile tests here. Its time to pass it back to you Guido for the win32 test. I think that will be better for us to use a wrapper for the functions, something like squid-getaddrinfo(), this will allow a simpler usage on Windows (see my previous mail). I'm kind of expecting another set of errors off these. It's just a matter of which ones. snip err fixed earlier. I think that's everything now. CVS is compiling again here. Should be ready again for your next test. OK, now I'm working on strtoll() fix. I will do some work on your code when finished. See tomorrow, I'm going to a barbecue with friends, today in Italy is a Holiday. :-) My turn for a few days holiday now. :-) This one is fully offline :-( An offline day may be a fortune :-) Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: IPv6 support and Windows
Hi Amos, At 07.25 15/08/2007, Amos Jeffries wrote: Hi Amos, Not good news here ... :-( We have a problem: You have used getaddrinfo() and freeaddrinfo() functions, but on Windows they are available only starting from Windows XP. This means that your code, even if compiled without IPv6 support, cannot run on Windows 2000. I'm also not sure if getaddrinfo() and freeaddrinfo() functions are available on all systems, someone know something about ? We have already tested Linux 2.6+ and FreeBSD 4.5+ (4.3 _says_ it has them) Not sure about Solaris, OS2, or Darwin yet. I have just imported and properly wrapped the libesmtp getaddrinfo and supporting implementation from fetchmail 6.3.8. I have done some simple configure and compile tests here. Its time to pass it back to you Guido for the win32 test. I think that will be better for us to use a wrapper for the functions, something like squid-getaddrinfo(), this will allow a simpler usage on Windows (see my previous mail). I'm kind of expecting another set of errors off these. It's just a matter of which ones. snip err fixed earlier. I think that's everything now. CVS is compiling again here. Should be ready again for your next test. See tomorrow, I'm going to a barbecue with friends, today in Italy is a Holiday. :-) My turn for a few days holiday now. :-) This one is fully offline :-( Amos
Re: IPv6 support and Windows
Hi Amos, At 00.13 15/08/2007, Amos Jeffries wrote: Hi Amos, Not good news here ... :-( We have a problem: You have used getaddrinfo() and freeaddrinfo() functions, but on Windows they are available only starting from Windows XP. This means that your code, even if compiled without IPv6 support, cannot run on Windows 2000. I'm also not sure if getaddrinfo() and freeaddrinfo() functions are available on all systems, someone know something about ? We have already tested Linux 2.6+ and FreeBSD 4.5+ (4.3 _says_ it has them) Not sure about Solaris, OS2, or Darwin yet. We also must check OpenBSD, NetBSD, Tru64, Irix and AIX. I have the first four. I have found two interesting substitute here: AYJ: pulled these out of order due to my response sequence http://doxygen.postgresql.org/getaddrinfo_8c-source.html I'm not sure if the licensing of the implementation coming from the PostgreSQL allow its usage in Squid. PostGres looks good until I audit the code. These are both killer bugs for us: Bugs: - only one addrinfo is set even though hintp is NULL or ai_socktype is 0 - AI_CANONNAME is not supported. http://www.koders.com/c/fid11C8C256BE9D1C263E0725F657383F62F24759F5.aspx?s=md5 The very first line says it's a (partial) implementation which makes me think there are edge cases missing, etc. Though a quick check of the code I couldn't see any obvious problems or notes about killer bugs. I'm sure there are more re-writes around, and sure enough Google codesearch find me a clean fetchmail implementation of JUST getaddrinfo(), freeaddrinfo() and gai_strerror(). ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/fetchmail-6.3.6.tar.gzcs_f=fetchmail-6.3.6/libesmtp/getaddrinfo.c#a0 That is probably better for us being more complete in the IPv4-area. The crunch now will be whether getnameinfo() is also that unsupported in NT/2k ? We must mix this code with the PostgreSQL one: on Windows the usage of native functions when available is mandatory. And sure, also getnameinfo() is not available on Windows 2000. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: IPv6 support and Windows
Hi Amos, At 07.25 15/08/2007, Amos Jeffries wrote: Hi Amos, Not good news here ... :-( We have a problem: You have used getaddrinfo() and freeaddrinfo() functions, but on Windows they are available only starting from Windows XP. This means that your code, even if compiled without IPv6 support, cannot run on Windows 2000. I'm also not sure if getaddrinfo() and freeaddrinfo() functions are available on all systems, someone know something about ? I have just imported and properly wrapped the libesmtp getaddrinfo and supporting implementation from fetchmail 6.3.8. I have done some simple configure and compile tests here. Its time to pass it back to you Guido for the win32 test. I think that will be better for us to use a wrapper for the functions, something like squid-getaddrinfo(), this will allow a simpler usage on Windows (see my previous mail). True. x seems to be the preferred prefix. I'll also see about wrap/include of the dependancy functions individually. ANYONE: Is anyone able to confirm for me whether I'm supposed to be using AC_SEARCH_LIBS() or AC_FUNC_CHECK() to do that properly? I'm kind of expecting another set of errors off these. It's just a matter of which ones. For now look for an undefined IPv6 into ACLIP.cc (line 296). Fixed. See tomorrow, I'm going to a barbecue with friends, today in Italy is a Holiday. :-) happy holiday :-) Amos
Re: IPv6 support and Windows
On tis, 2007-08-14 at 13:41 +0200, Guido Serassio wrote: I'm not sure if the licensing of the implementation coming from the PostgreSQL allow its usage in Squid. Looks fine. PostgreSQL is licensed under the modified/modern three-clause BSD license, which is fully GPL compatible. http://www.postgresql.org/about/licence Regards Henrik signature.asc Description: This is a digitally signed message part
Re: IPv6 support and Windows
Hi Amos, Not good news here ... :-( We have a problem: You have used getaddrinfo() and freeaddrinfo() functions, but on Windows they are available only starting from Windows XP. This means that your code, even if compiled without IPv6 support, cannot run on Windows 2000. I'm also not sure if getaddrinfo() and freeaddrinfo() functions are available on all systems, someone know something about ? We have already tested Linux 2.6+ and FreeBSD 4.5+ (4.3 _says_ it has them) Not sure about Solaris, OS2, or Darwin yet. I have found two interesting substitute here: AYJ: pulled these out of order due to my response sequence http://doxygen.postgresql.org/getaddrinfo_8c-source.html I'm not sure if the licensing of the implementation coming from the PostgreSQL allow its usage in Squid. PostGres looks good until I audit the code. These are both killer bugs for us: Bugs: - only one addrinfo is set even though hintp is NULL or ai_socktype is 0 - AI_CANONNAME is not supported. http://www.koders.com/c/fid11C8C256BE9D1C263E0725F657383F62F24759F5.aspx?s=md5 The very first line says it's a (partial) implementation which makes me think there are edge cases missing, etc. Though a quick check of the code I couldn't see any obvious problems or notes about killer bugs. I'm sure there are more re-writes around, and sure enough Google codesearch find me a clean fetchmail implementation of JUST getaddrinfo(), freeaddrinfo() and gai_strerror(). ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/fetchmail-6.3.6.tar.gzcs_f=fetchmail-6.3.6/libesmtp/getaddrinfo.c#a0 That is probably better for us being more complete in the IPv4-area. The crunch now will be whether getnameinfo() is also that unsupported in NT/2k ? AND its already under GNU license to FSF. Amos
Re: IPv6 support and Windows
Hi Amos, Not good news here ... :-( We have a problem: You have used getaddrinfo() and freeaddrinfo() functions, but on Windows they are available only starting from Windows XP. This means that your code, even if compiled without IPv6 support, cannot run on Windows 2000. I'm also not sure if getaddrinfo() and freeaddrinfo() functions are available on all systems, someone know something about ? We have already tested Linux 2.6+ and FreeBSD 4.5+ (4.3 _says_ it has them) Not sure about Solaris, OS2, or Darwin yet. I have just imported and properly wrapped the libesmtp getaddrinfo and supporting implementation from fetchmail 6.3.8. I have done some simple configure and compile tests here. Its time to pass it back to you Guido for the win32 test. I'm kind of expecting another set of errors off these. It's just a matter of which ones. Amos
RE: IPv6 support
I was responsible for the first Squid IPv6 patch destined to bit-rot. Having observed the error of my ways if not actually learnt by re-doing, I second Adrian's excellent advice! Also it is important to emphasise Henrik's point that Squid still needs to compile on boxes that do not have the standard IPv6 facilities available, ie. There needs to be at least a couple of ifdef's retained forever, although as few as possible is preferable. Roger. -Original Message- From: Adrian Chadd [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 March 2005 12:58 PM To: squid-dev@squid-cache.org Subject: Re: IPv6 support I know this may not be completely relevant to the ipv6 discussion, but you buy a lot of flexibility if you abstract out the socket API /usefully/. You're then able to do the following: * easily deal with the different crack unices have when twiddling socket stuff (eg, via ioctls, grabbing the source address of connections in client_side.c(c) or http.c(c), etc.) * supporting wildly(!) different APIs, such as windows The only place I see this really breaking is in the ACL code. Adrian -- Adrian ChaddYou don't have a TV? Then what's [EMAIL PROTECTED] all your furniture pointing at?
Re: IPv6 support
Henrik Nordstrom wrote: On Thu, 24 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: Also, it would be nice if Henrik could start with some comments he said to have on these first IPv6 steps. :-) I am still here ;-) The main comment is that we should try to cut down on the number of #ifdefs. I prefer introducing a new class to abstract the address info even if this is just a thin or almost transparent wrapper around sockaddr_in or in_addr when ipv6 is not enabled. Hehe, I'm not a friend of #ifdefs. In my programming language of choice, #ifdefs are unknown. But the current CVS HEAD is only partially object orientized, and especially the code which does address handling and the like is currently not enough object orientized to do just a drop in replacement of a class. The #if ENABLE_IPV6 conditions are to provide a more smooth transition to enabled IPv6 support. The idea is: When ENABLE_IPV6==0, then everything is as before. But when ENABLE_IPV6==1, every variable and every struct which refers IPv4 adresses (the old way) just do not exist. This triggers compiler error messages, which show automagically where those variables and structs where referenced. This is used to find the next places where conversion work has to be done. If no compiler error messages are left, we either are finished or at least have converted a complete, independent subsystem. This approach (of breaking compileability with intent) has the side effect that, until IPv6 support has been provided nearly completely, the modified code would not compile. Thus, the modification is encapsulated by #if ENABLE_IPV6 to protect uninterested developers to be forced to fix IPv6 generated compiler error messages. Because IP address encapsulation is lacking, just subclassing an Address class to an IPv6Address class is not possible (the Address class is missing... ;-)). That is why I think that this, under these circumstances, is a good approach. (I think that this is also better than letting IPv6 support dangle in a separate branch, because if someone hacks on the main branch and wand wants to change code within an #if ENABLE_IPV6 ... #endif section, then this guy then has the opportunity to Do It Right The First Time (tm) if he|she likes. If not, then changing the #else..#endif subsection will still be fine. At least nobody hacking the HEAD tree would be able to create a failed sync between HEAD and squid-ipv6 branches, because a separate squid-ipv6 branch would not exist, the #if ENABLE_IPV6 sections are the branch.) Having #if ENABLE_IPV6 statements should be only temporary. When there are no IPv6 support compile error messages anymore, ENABLE_IPV6==1 should become the default. After some more testing, all #if ENABLE_IPV6 /* new code */ #else /* old code */ #endif sections in the sourcecode shall be replaced by /* new code */ so the #if ENABLE_IPV6 statements will then be removed, too. This will be possible, because ENABLE_IPV6 does not really mean that we are going away from IPv4, but just that the software will be IP version neutral, explicitly supporting both IPv4 and IPv6. Regards Henrik So far, Xuân. :-)
Re: IPv6 support
On Thu, 3 Mar 2005, [ISO-8859-1] Xuân Baldauf wrote: The #if ENABLE_IPV6 conditions are to provide a more smooth transition to enabled IPv6 support. The idea is: When ENABLE_IPV6==0, then everything is as before. But when ENABLE_IPV6==1, every variable and every struct which refers IPv4 adresses (the old way) just do not exist. I know, and this is what I dislike. By using the ifdefs, the IPv6 code can not be introduced into HEAD in a meaningful manner as it is bound to bitrot pretty quickly unless all developers switches to build their Squids IPv6 enabled, as even trivial errors won't be detected compile time. Also it considerably obfuscates the code and makes maintenance a burden. Yes, doing it proper from start may requires a little bigger initial effort, but only marginally so I think (not counting the effort you have already put into doing it..). In both cases a new type for ipv6 needs to be introduced, and in both cases the compiler will tell you which lines is affected due to the type change. This approach (of breaking compileability with intent) has the side effect that, until IPv6 support has been provided nearly completely, the modified code would not compile. Thus, the modification is encapsulated by #if ENABLE_IPV6 to protect uninterested developers to be forced to fix IPv6 generated compiler error messages. The same can be acheived by providing a typecast operator to the old address types only when IPv6 is not enabled and use this in the glue between converted and not yet converted code. In addition, this part of the discussion is only interesting when it comes to merging the IPv6 support into HEAD, not the initial efforts. lacking, just subclassing an Address class to an IPv6Address class is not possible (the Address class is missing... ;-)). Only because something is missing does not say it should stay that way. It should not stay that way. HEAD tree would be able to create a failed sync between HEAD and squid-ipv6 branches, because a separate squid-ipv6 branch would not exist, the #if ENABLE_IPV6 sections are the branch.) The current #if ENABLE_IPV6 won't make it into HEAD for the reasons outlined above. This style of programming is bound to stay in a separate branch until done proper. Having #if ENABLE_IPV6 statements should be only temporary. When there are no IPv6 support compile error messages anymore, ENABLE_IPV6==1 should become the default. After some more testing, all #if ENABLE_IPV6 /* new code */ #else /* old code */ #endif sections in the sourcecode shall be replaced by /* new code */ so the #if ENABLE_IPV6 statements will then be removed, too. This will be possible, because ENABLE_IPV6 does not really mean that we are going away from IPv4, but just that the software will be IP version neutral, explicitly supporting both IPv4 and IPv6. Not all OS:es where Squid builds is IPv6 enabled which complicates matters somewhat. By introducing a new proper address class this dependency gets isolated down to the address class, keeping the bulk of the code clean. Regards Henrik
Re: IPv6 support
I know this may not be completely relevant to the ipv6 discussion, but you buy a lot of flexibility if you abstract out the socket API /usefully/. You're then able to do the following: * easily deal with the different crack unices have when twiddling socket stuff (eg, via ioctls, grabbing the source address of connections in client_side.c(c) or http.c(c), etc.) * supporting wildly(!) different APIs, such as windows The only place I see this really breaking is in the ACL code. Adrian -- Adrian ChaddYou don't have a TV? Then what's [EMAIL PROTECTED] all your furniture pointing at?
Re: IPv6 support
Alex Rousskov wrote: On Tue, 2005/02/15 (MST), [EMAIL PROTECTED] wrote: I'm trying to bring forward IPv6 support of squid. FYI: You can try to use Web Polygraph to test performance aspects of IPv6 support in Squid. For example, it may be useful to compare IPv4 and IPv6 performance (with or without DNS) on an otherwise identical workload. You can start with a standard workload and then modify it to intensify operations that affect IP version the most. I do not know if anybody is actively using IPv6 code in Polygraph now, but it used to work. HTH, Alex. Thank you, Alex, for notifying me. Although, I do not expect any noticable changes regarding performance wether IPv6 is switched on or not. But it may worth testing this - at least if IPv6 was compileable. I have made some first steps, but it would be nice if someone could help continueing those steps. ;-) Also, it would be nice if Henrik could start with some comments he said to have on these first IPv6 steps. :-) ciao, Xuân.
Re: IPv6 support
On Wed, 16 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: Further investigation showed: nearly all my IPv6 changes were not distributed into the squid-ipv6 branch, but into the HEAD branch. Ok. What probably happened was the same as for the Root, only the top level directory was correct. No harm done to HEAD however. This HEAD is just a shadow of the release CVS on squid-cache.org and is automatically reset each night. So somehow, I have managed by accident to circumvent whatever access restrictions! Yes, these access controls is by no means ment to be secure, merely a guide trapping most common errors. What is important is that you recover your changes so they can be applied to the correct branch. Regards Henrik
Re: IPv6 support
On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: I'm trying to bring forward IPv6 support of squid. I have created a patch (see http://www.squid-cache.org/bugs/show_bug.cgi?id=1026 ). Henrik Nordstrom recommended to subscribe squid-dev@squid-cache.org in order to discuss this patch, so here I am. :-) Welcome! P.S.: Henrik, I created a squid-ipv6 branch as you recommended. But Step 7 of http://devel.squid-cache.org/CVS.html (Step by step guide for creating and using a new branch from HEAD) fails: # cvs commit [...] cvs [server aborted]: commit requires write access to the repository cvs commit: saving log message in /tmp/cvsmO7hax # Odd.. you should have write permission. What repository root did you use? grep . CVS/Root CVS/Repository CVS/Tag Regards Henrik
Re: IPv6 support
Henrik Nordstrom wrote: On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: I'm trying to bring forward IPv6 support of squid. I have created a patch (see http://www.squid-cache.org/bugs/show_bug.cgi?id=1026 ). Henrik Nordstrom recommended to subscribe squid-dev@squid-cache.org in order to discuss this patch, so here I am. :-) Welcome! :-) P.S.: Henrik, I created a squid-ipv6 branch as you recommended. But Step 7 of http://devel.squid-cache.org/CVS.html (Step by step guide for creating and using a new branch from HEAD) fails: # cvs commit [...] cvs [server aborted]: commit requires write access to the repository cvs commit: saving log message in /tmp/cvsmO7hax # Odd.. you should have write permission. What repository root did you use? grep . CVS/Root CVS/Repository CVS/Tag linux-notebook:~/work/squid/cvs/squid3-ipv6 # grep . CVS/Root CVS/Repository CVS/Tag CVS/Root:[EMAIL PROTECTED]:/cvsroot/squid CVS/Repository:squid3 CVS/Tag:Tsquid3-ipv6 Maybe I have checked out at a directory level to high...? Regards Henrik
Re: IPv6 support
On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: Odd.. you should have write permission. What repository root did you use? grep . CVS/Root CVS/Repository CVS/Tag CVS/Root:[EMAIL PROTECTED]:/cvsroot/squid CVS/Repository:squid3 CVS/Tag:Tsquid3-ipv6 Maybe I have checked out at a directory level to high...? Everything looks just right to me. CVS Root: [EMAIL PROTECTED]:/cvsroot/squid [OK] Module: squid3 [OK] Tag: squid3-ipv6 [OK] If you still have trouble try filing a Sourceforge support request to see if the support staff can look into what the issue may be. They are usually quite responsive. Regards Henrik
Re: IPv6 support
Henrik Nordstrom wrote: On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: Odd.. you should have write permission. What repository root did you use? grep . CVS/Root CVS/Repository CVS/Tag CVS/Root:[EMAIL PROTECTED]:/cvsroot/squid CVS/Repository:squid3 CVS/Tag:Tsquid3-ipv6 Maybe I have checked out at a directory level to high...? Everything looks just right to me. CVS Root: [EMAIL PROTECTED]:/cvsroot/squid [OK] Module: squid3 [OK] Tag: squid3-ipv6 [OK] Hi Henrik, I think I found the reason: The CVS/Root file of the top level directory was correct, but the CVS/Root file of the lower level directories were not changed by the cvsmkbranch script. Thus, I effectively tried to commit the lower directory files as anonymous, which should fail and actually failed. (I checked out as anonymous first, because checking out using SSH did not work at that time). I now checked in all changes to the squid-ipv6 branch, and I'm waiting for discussion. :-) If you still have trouble try filing a Sourceforge support request to see if the support staff can look into what the issue may be. They are usually quite responsive. Regards Henrik ciao, Xuân.
Re: IPv6 support
On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: I think I found the reason: The CVS/Root file of the top level directory was correct, but the CVS/Root file of the lower level directories were not changed by the cvsmkbranch script. cvsmkbranch does not change any CVS/Root files, but never mind, what is important is that you got it to work. I now checked in all changes to the squid-ipv6 branch, and I'm waiting for discussion. :-) Have you also set up the project page? (easier to inspect the branch that way) Regards Henrik
Re: IPv6 support
Henrik Nordstrom wrote: On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: I think I found the reason: The CVS/Root file of the top level directory was correct, but the CVS/Root file of the lower level directories were not changed by the cvsmkbranch script. cvsmkbranch does not change any CVS/Root files, but never mind, what is important is that you got it to work. Oh. :-) I now checked in all changes to the squid-ipv6 branch, and I'm waiting for discussion. :-) Have you also set up the project page? (easier to inspect the branch that way) Now I have (but the change has not yet been distributed to http://devel.squid-cache.org/projects.html , but I expect this to be just a matter of time :-)). Regards Henrik
Re: IPv6 support
Xuân Baldauf wrote: Henrik Nordstrom wrote: On Tue, 15 Feb 2005, [ISO-8859-1] Xuân Baldauf wrote: Odd.. you should have write permission. What repository root did you use? grep . CVS/Root CVS/Repository CVS/Tag CVS/Root:[EMAIL PROTECTED]:/cvsroot/squid CVS/Repository:squid3 CVS/Tag:Tsquid3-ipv6 Maybe I have checked out at a directory level to high...? Everything looks just right to me. CVS Root: [EMAIL PROTECTED]:/cvsroot/squid [OK] Module: squid3 [OK] Tag: squid3-ipv6 [OK] Hi Henrik, I think I found the reason: The CVS/Root file of the top level directory was correct, but the CVS/Root file of the lower level directories were not changed by the cvsmkbranch script. Thus, I effectively tried to commit the lower directory files as anonymous, which should fail and actually failed. (I checked out as anonymous first, because checking out using SSH did not work at that time). I now checked in all changes to the squid-ipv6 branch, Sorry Henrik, As I have been searching for the changes I made to the squid-ipv6 branch by using http://cvs.sourceforge.net/viewcvs.py/squid/squid3/lib/?only_with_tag=squid3-ipv6 , I could not find my changes in safe_inet_addr.c. I thought, this is due to a CVS server to viewcvs delay. Then I have checked out again both the whole HEAD branch and also the squid-ipv6 branch of squid3, because my older changed squid branch (checked out as anonymous) was messed (because cvs then tries to checkin as anonymous also). After trying to compile the latter branch with ./configure --enable-ipv6, I found out that the compile worked absolutely cleanly, which was not expected. Further investigation showed: nearly all my IPv6 changes were not distributed into the squid-ipv6 branch, but into the HEAD branch. I thought this was not possible due to access restrictions. I checked wether there are access restrictions, and actually, there are: ERROR: You do not have permission to commit on the HEAD branch of squid3. Please contact the project administrator if you think this is in error, asking him to add permission for mediumnet. cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! So somehow, I have managed by accident to circumvent whatever access restrictions! I knew, because not all my changes did not reach HEAD, current HEAD would not compile. Therefore, I tried to reproduce this and after about one hour of fiddling, I actually succeeded. I checked in a small change to ./configure.in which should make HEAD compileable again. (However, as it is 4:41 CET, I need to sleep and thus, I currently cannot verify that.) and I'm waiting for discussion. :-) If you still have trouble try filing a Sourceforge support request to see if the support staff can look into what the issue may be. They are usually quite responsive. Regards Henrik ciao, Xuân.
