Re: Release date for Privoxy 3.0.19 stable

On 12/29/11, Fabian Keil <[email protected]> wrote:
> Lee <[email protected]> wrote:
>
>> On 12/28/11, Fabian Keil <[email protected]> wrote:
>> > Lee <[email protected]> wrote:
>> >
>> >> On 12/28/11, Fabian Keil <[email protected]> wrote:
>> >> > Lee <[email protected]> wrote:
>> >> >
>> >> >> On 12/27/11, Fabian Keil <[email protected]> wrote:
>> >> >> > Lee <[email protected]> wrote:
>> >> >
>> >> >> >> I finally got around to checking email again..  Windows build is
>> >> >> >> up
>> >> >> >> on
>> >> >> >> SF and, after a bit of poking around, privoxy-setup 3.0.19 is the
>> >> >> >> default windows download :)
>> >> >> >
>> >> >> > Great. I assume you built it with IPv6 support?
>> >> >>
>> >> >> Yes.  I did the build on a Vista machine using winsetup/GNUmakefile
>> >> >> so
>> >> >> the configure options were
>> >> >>   ./configure --enable-mingw32 --disable-pthread
>> >> >> --disable-dynamic-pcre --enable-zlib
>> >> >
>> >> > It's unfortunate that --disable-dynamic-pcre seems to be
>> >> > necessary on Windows, but other than that these look like
>> >> > reasonable settings for most users.
>> >>
>> >> All that's required is "./configure --enable-mingw32".
>> >
>> > My main concern (which I didn't clearly articulate above) is that
>> > the outdated internal pcre version is used. At least a few years
>> > ago linking to a more recent version wasn't an option on Windows.
>>
>> Ahh..  yes, I missed that.
>>
>> Does the internal pcre version have modifications to handle the host
>> part of regular expressions in the action files or is it two separate
>> functions?  eg
>> .example.com/
>> matches any host name ending in ".example.com".  A normal [??] RE
>> would treat the periods as match any single character.  Privoxy
>> doesn't treat periods as wildcards until after a "/" character.
>
> No such modifications are necessary as Privoxy doesn't use
> pcre for the host part of the URL pattern at all,

??
It seems like it has to use something since it isn't a straight text match..
Oh well, I'll try to follow the code & figure it out

> unless it has
> been configured to do so with --enable-extended-host-patterns.
>
> Quoting the description:
> | Enable and require PCRE syntax in host patterns. This feature hasn't
> | been announced yet and it's not clear if it's a good idea. It's expected
> | to work, but undocumented. You should only enable it if you know what
> | PCRE is and are sure that you need it for your host patterns. You can
> | use tools/url-pattern-translator.pl to convert existing action files to
> | use PCRE host patterns. Please don't enable this option when creating
> | packages for others that may not be expecting it.
>
> TODO list item #80 is also relevant:
>
> | Change FEATURE_EXTENDED_HOST_PATTERNS to support both
> | extended and vanilla host patterns at the same time.

Right, that one - "vanilla host patterns".  That's not a [modified?]
PCRE package?

Where I was trying to go with the question was finding out if there's
two separate packages - "host patterns" and whatever comes after the
host part.  If it's all one package with modifications for matching
host patterns then upgrading to the current PCRE libs + backporting
Privoxy modifications to the library is going to be *much* harder.

If it's two separate packages there's a slightly better chance I can
figure out how to upgrade the windows version of Privoxy to the
current pcre library.

   [.. snip domain regex possible options ..]
>> >> > Interesting. We probably shouldn't use that define when
>> >> > --disable-ipv6-support has been used anyway.
>> >>
>> >> Probably not.. dunno if it's worth the effort to redo the code when we
>> >> could just do a
>> >> #ifndef NI_MAXSERV
>> >
>> > Using our own define, naming it to something like
>> > MAX_PORTSTRING_LENGTH and setting it to NI_MAXSERV
>> > if it's available, and 32 otherwise, would also make
>> > the code easier to read (I think), so I'd consider it
>> > worth it.
>>
>> Whatever you think is best.  I got lost trying to figure out how
>> configure did it's thing & ended up putting the define of NI_MAXSERV
>> in jbsockets.c
>
> configure has no magic to satisfy the requirement for a
> NI_MAXSERV definition in jbsockets.c if IPv6 is disabled.

Not that I could follow it, but it sure seems to create header files.
I was thinking it'd be nice if all the required header files were
pulled in regardless of IPv6 being enabled or not & leaving out the
WinXP and later library calls if IPv6 was disabled.

> It just happens to work by accident on most platforms other
> than Windows as <netdb.h> in included unconditionally there.

^shrug^  I don't know enough to comment.  Which is probably why I
spent time trying to figure out how to get the right headers included
without pulling in the libraries that don't exist on Win98 etc.  :)


>> diff -U4 /cvs/privoxy/current/jbsockets.c current/jbsockets.c
>> --- /cvs/privoxy/current/jbsockets.c    2011-12-18 17:00:39.731285800
>> -0500
>> +++ current/jbsockets.c 2011-12-28 23:53:48.007010200 -0500
>> @@ -961,8 +961,16 @@
>>  #endif /* def HAVE_GETHOSTBYADDR_R_(8|7|5)_ARGS */
>>  #endif /* ifndef HAVE_RFC2553 */
>>     s_length = s_length_provided = sizeof(server);
>>
>> +
>> +/* work-around for "./configure --enable-mingw32 --disable-ipv6-support"
>> not
>> + * pulling in whatever it is that defines NI_MAXSERV
>> + */
>> +#ifndef NI_MAXSERV
>> +#define NI_MAXSERV 32
>> +#endif /* NI_MAXSERV is undefined */
>> +
>>     if (NULL != hostname)
>>     {
>>        *hostname = NULL;
>>     }
>>
>>
>> That works, http://config.privoxy.org/show-status says
>> FEATURE_IPV6_SUPPORT 	No 	Allows IPv6 addresses in incoming requests,
>> when resolving domains to IP addresses and in the configuration files.
>>
>> and ws2_32 is not pulled in as a library:
>
>> So are you OK with adding
>>   #ifndef NI_MAXSERV
>>   #define NI_MAXSERV 32
>>   #endif /* NI_MAXSERV is undefined */
>> to jbsockets.c  ... at least as a short-term work-around?
>
> Yes.

OK - I'll put up an IPv4 only version of Privoxy on SF with just that
change in it

Lee

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox