You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Igor Galić <i....@brainsware.org> on 2011/09/23 17:52:27 UTC
t/r 3.0.2
Hi folks,
I'm planning to tag 3.0.2 by Tuesday (Sept 27th, 2011), so I
kindly asked everybody who hasn't looked at 3.0.x' STATUS file
https://svn.apache.org/repos/asf/trafficserver/traffic/branches/3.0.x/STATUS
in a long time to do so now. Please cast your votes or concerns
for the remaining.
So long, and thanks for all the <><
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
I have not been able to reproduce this… Anyone else?
On Oct 5, 2011, at 2:21 PM, Jim Jagielski wrote:
> Let me reproduce...
> On Oct 5, 2011, at 6:51 AM, Igor Galić wrote:
>
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> ----- Original Message -----
>>>> Should we set some deadline? I can RM if need be.
>>>
>>> Currently doing tests as users reported a regression on parent
>>> caching
>>
>>
>> The setup
>>
>> /opt/ats-3.0.x/ -- The proxy
>> ============================
>>
>> listening on port 80
>>
>> records.config: proxy.config.http.parent_proxy_routing_enable 1
>>
>> parent.config: dest_domain=. parent=127.0.0.1:9090
>>
>> remap.config: map / http://127.0.0.1:8080/
>>
>>
>> /opt/ats-3.0.y/ -- The parent
>> =============================
>>
>> listening on port 9090 (909x)
>>
>> remap.config: map / http://127.0.0.1:8080/
>>
>>
>> Result:
>> =======
>>
>> A request to an uncached site always looks like this:
>>
>> 1317811136.027 1 127.0.0.1 TCP_MISS/200 14350 GET http://127.0.0.1:8080/index.html - DIRECT/127.0.0.1 text/html -
>>
>>
>> i
>>
>> --
>> Igor Galić
>>
>> Tel: +43 (0) 664 886 22 883
>> Mail: i.galic@brainsware.org
>> URL: http://brainsware.org/
>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>>
>
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Let me reproduce...
On Oct 5, 2011, at 6:51 AM, Igor Galić wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> Should we set some deadline? I can RM if need be.
>>
>> Currently doing tests as users reported a regression on parent
>> caching
>
>
> The setup
>
> /opt/ats-3.0.x/ -- The proxy
> ============================
>
> listening on port 80
>
> records.config: proxy.config.http.parent_proxy_routing_enable 1
>
> parent.config: dest_domain=. parent=127.0.0.1:9090
>
> remap.config: map / http://127.0.0.1:8080/
>
>
> /opt/ats-3.0.y/ -- The parent
> =============================
>
> listening on port 9090 (909x)
>
> remap.config: map / http://127.0.0.1:8080/
>
>
> Result:
> =======
>
> A request to an uncached site always looks like this:
>
> 1317811136.027 1 127.0.0.1 TCP_MISS/200 14350 GET http://127.0.0.1:8080/index.html - DIRECT/127.0.0.1 text/html -
>
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
>
>
> ----- Original Message -----
> > Should we set some deadline? I can RM if need be.
>
> Currently doing tests as users reported a regression on parent
> caching
The setup
/opt/ats-3.0.x/ -- The proxy
============================
listening on port 80
records.config: proxy.config.http.parent_proxy_routing_enable 1
parent.config: dest_domain=. parent=127.0.0.1:9090
remap.config: map / http://127.0.0.1:8080/
/opt/ats-3.0.y/ -- The parent
=============================
listening on port 9090 (909x)
remap.config: map / http://127.0.0.1:8080/
Result:
=======
A request to an uncached site always looks like this:
1317811136.027 1 127.0.0.1 TCP_MISS/200 14350 GET http://127.0.0.1:8080/index.html - DIRECT/127.0.0.1 text/html -
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Should we set some deadline? I can RM if need be.
Currently doing tests as users reported a regression on parent caching
> On Oct 3, 2011, at 2:03 PM, Jim Jagielski wrote:
>
> > Gone as far as I can on STATUS…
> >
> > On Sep 30, 2011, at 7:20 AM, Jim Jagielski wrote:
> >
> >> Will look today… Not sure if I'll have time to do the actual
> >> commits but will be able to at least finish testing and voting…
> >>
> >> On Sep 29, 2011, at 11:43 AM, Igor Galić wrote:
> >>
> >>> Hey guys,
> >>>
> >>> just a soft reminder that there's still a couple of issues
> >>> that are easy fixes but need your vote
> >>>
> >>> i
> >>>
> >>> --
> >>> Igor Galić
> >>>
> >>> Tel: +43 (0) 664 886 22 883
> >>> Mail: i.galic@brainsware.org
> >>> URL: http://brainsware.org/
> >>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
> >>>
> >
>
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Should we set some deadline? I can RM if need be.
On Oct 3, 2011, at 2:03 PM, Jim Jagielski wrote:
> Gone as far as I can on STATUS…
>
> On Sep 30, 2011, at 7:20 AM, Jim Jagielski wrote:
>
>> Will look today… Not sure if I'll have time to do the actual
>> commits but will be able to at least finish testing and voting…
>>
>> On Sep 29, 2011, at 11:43 AM, Igor Galić wrote:
>>
>>> Hey guys,
>>>
>>> just a soft reminder that there's still a couple of issues
>>> that are easy fixes but need your vote
>>>
>>> i
>>>
>>> --
>>> Igor Galić
>>>
>>> Tel: +43 (0) 664 886 22 883
>>> Mail: i.galic@brainsware.org
>>> URL: http://brainsware.org/
>>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>>>
>
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Gone as far as I can on STATUS…
On Sep 30, 2011, at 7:20 AM, Jim Jagielski wrote:
> Will look today… Not sure if I'll have time to do the actual
> commits but will be able to at least finish testing and voting…
>
> On Sep 29, 2011, at 11:43 AM, Igor Galić wrote:
>
>> Hey guys,
>>
>> just a soft reminder that there's still a couple of issues
>> that are easy fixes but need your vote
>>
>> i
>>
>> --
>> Igor Galić
>>
>> Tel: +43 (0) 664 886 22 883
>> Mail: i.galic@brainsware.org
>> URL: http://brainsware.org/
>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>>
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Will look today… Not sure if I'll have time to do the actual
commits but will be able to at least finish testing and voting…
On Sep 29, 2011, at 11:43 AM, Igor Galić wrote:
> Hey guys,
>
> just a soft reminder that there's still a couple of issues
> that are easy fixes but need your vote
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
Hey guys,
just a soft reminder that there's still a couple of issues
that are easy fixes but need your vote
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@apache.org>.
That's silly… We *know* that endp and p are char* (and
to the same object) and so any comparison is allowed without
any weird casts…
The real fix is:
if (endp < p)
On Sep 25, 2011, at 7:35 PM, Igor Galić wrote:
>
>
> ----- Original Message -----
>> for sure… mixing pointers and ints is Do Not Do In C 101.
>> Tracking the full issue…
>
> Here's how we deal with that on trunk:
>
>
> @@ -1863,7 +1861,7 @@
> c->freeall();
> p = (char *) DOUBLE_ALIGN(p);
> #ifdef PURIFY
> - if ((unsigned int) endp < (unsigned int) p)
> + if ((uintptr_t) endp < (uintptr_t) p)
> memset(endp, 0, (p - endp));
> #endif
> }
>
>
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> for sure… mixing pointers and ints is Do Not Do In C 101.
> Tracking the full issue…
Here's how we deal with that on trunk:
@@ -1863,7 +1861,7 @@
c->freeall();
p = (char *) DOUBLE_ALIGN(p);
#ifdef PURIFY
- if ((unsigned int) endp < (unsigned int) p)
+ if ((uintptr_t) endp < (uintptr_t) p)
memset(endp, 0, (p - endp));
#endif
}
n.b.: I recently enabled --enable-purify for all buildbots in order
> > The first is 64 bits on most systems an the latter is 32 bits on
> > all (supported) systems.
> >
> > --
> > Theo Schlossnagle (mobile)
> > http://omniti.com/is/theo-schlossnagle
> >
> > On Sep 24, 2011, at 9:10 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> >> Weird…
> >>
> >> ClusterHandler.cc:1866: error: cast from 'char*' to 'unsigned
> >> int' loses precision
> >>
> >> trying to recreate here… will find and fix :)
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
for sure… mixing pointers and ints is Do Not Do In C 101.
Tracking the full issue…
On Sep 24, 2011, at 9:15 AM, Theo Schlossnagle wrote:
> The first is 64 bits on most systems an the latter is 32 bits on all (supported) systems.
>
> --
> Theo Schlossnagle (mobile)
> http://omniti.com/is/theo-schlossnagle
>
> On Sep 24, 2011, at 9:10 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Weird…
>>
>> ClusterHandler.cc:1866: error: cast from 'char*' to 'unsigned int' loses precision
>>
>> trying to recreate here… will find and fix :)
>>
>> On Sep 23, 2011, at 4:51 PM, Igor Galić wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> Votes cast; patched promoted and committed :)
>>>
>>> Thank you jim!
>>>
>>> ...and something went wrong:-/
>>>
>>>
>>> 20:56:41 < tserver-bot> build #13 of tserver-branch3.0.x is complete: Failure [failed compile_2] Build details are at http://ci.apache.org/builders/tserver-branch3.0.x/builds/13 blamelist: jim
>>>
>>> I have yet to examine it, but not tonight anymore.
>>>
>>> i
>>>
>>> --
>>> Igor Galić
>>>
>>> Tel: +43 (0) 664 886 22 883
>>> Mail: i.galic@brainsware.org
>>> URL: http://brainsware.org/
>>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>>>
>>
>
Re: t/r 3.0.2
Posted by Theo Schlossnagle <je...@omniti.com>.
The first is 64 bits on most systems an the latter is 32 bits on all (supported) systems.
--
Theo Schlossnagle (mobile)
http://omniti.com/is/theo-schlossnagle
On Sep 24, 2011, at 9:10 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Weird…
>
> ClusterHandler.cc:1866: error: cast from 'char*' to 'unsigned int' loses precision
>
> trying to recreate here… will find and fix :)
>
> On Sep 23, 2011, at 4:51 PM, Igor Galić wrote:
>
>>
>>
>> ----- Original Message -----
>>> Votes cast; patched promoted and committed :)
>>
>> Thank you jim!
>>
>> ...and something went wrong:-/
>>
>>
>> 20:56:41 < tserver-bot> build #13 of tserver-branch3.0.x is complete: Failure [failed compile_2] Build details are at http://ci.apache.org/builders/tserver-branch3.0.x/builds/13 blamelist: jim
>>
>> I have yet to examine it, but not tonight anymore.
>>
>> i
>>
>> --
>> Igor Galić
>>
>> Tel: +43 (0) 664 886 22 883
>> Mail: i.galic@brainsware.org
>> URL: http://brainsware.org/
>> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>>
>
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Weird…
ClusterHandler.cc:1866: error: cast from 'char*' to 'unsigned int' loses precision
trying to recreate here… will find and fix :)
On Sep 23, 2011, at 4:51 PM, Igor Galić wrote:
>
>
> ----- Original Message -----
>> Votes cast; patched promoted and committed :)
>
> Thank you jim!
>
> ...and something went wrong:-/
>
>
> 20:56:41 < tserver-bot> build #13 of tserver-branch3.0.x is complete: Failure [failed compile_2] Build details are at http://ci.apache.org/builders/tserver-branch3.0.x/builds/13 blamelist: jim
>
> I have yet to examine it, but not tonight anymore.
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Votes cast; patched promoted and committed :)
Thank you jim!
...and something went wrong:-/
20:56:41 < tserver-bot> build #13 of tserver-branch3.0.x is complete: Failure [failed compile_2] Build details are at http://ci.apache.org/builders/tserver-branch3.0.x/builds/13 blamelist: jim
I have yet to examine it, but not tonight anymore.
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Votes cast; patched promoted and committed :)
On Sep 23, 2011, at 11:52 AM, Igor Galić wrote:
>
> Hi folks,
>
> I'm planning to tag 3.0.2 by Tuesday (Sept 27th, 2011), so I
> kindly asked everybody who hasn't looked at 3.0.x' STATUS file
>
> https://svn.apache.org/repos/asf/trafficserver/traffic/branches/3.0.x/STATUS
>
> in a long time to do so now. Please cast your votes or concerns
> for the remaining.
>
> So long, and thanks for all the <><
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
>
Re: t/r 3.0.2
Posted by Arno Töll <de...@toell.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 26.09.2011 01:30, Igor Galić wrote:
> Does that include 3.0.1 or
According to the user: yes (again: I couldn't neither verify nor test
that). Summarizing from IRC (quoted without permission, hence I replaced
the name):
<daemonkeeper> Did you now find a problem with the init script?
<user> it was a permission problem, but was gone when i installed the
newer package from debian
<daemonkeeper> Even better
<user> so just need to wait till canonical unfreezes
<daemonkeeper> You need to wait until Oneriric+1 to get my shiny, cool
Debian packages if you don't want to use Debian.
<user> but in that newer packages parent caching aint working
<user> so maybe put in a extra patch for that ;)
<daemonkeeper> Wait, you mean the Debian package has a problem with
parent caching, 3.0 did not have?
<user> daemonkeeper: they both have it it seems
<user> current running the 3.1.1 self-build version to resolve that
<user> i just found it out by tcpdumping the parent and origin and
seeing that the frontend contanted the origin directly even when a
parent was configured
> Can we track down what exactly is broken and what has fixed it?
I will see whether I can get the user to reply here.
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOf7wMAAoJEMcrUe6dgPNt108P/ArufqPoTh1jOtyjhrPeCxJZ
QmwisLd+3apAaZDxSsOf28Ql5Dg7uPqBs5ItCSi2HV0UVQGwiCwfCZOkYDmRAaOI
ILB3HOPBLXiOrrIzsjbp7ZTnSb91I1LYgHag2hs3q/IRV8QOdWDBXvPEeX+sBejP
xMnH27ydxgv7jbM4HPRkbNpStBMER41QGAeMbcmkL0vcdrJjJmmeqRi/18WpxntO
N5AoNduNCdkyiyetdp+CMEiUrsSRhoz/IZmKogATQl2KtqdocLN4EQcJTLPwb57n
dVKryaV0CC9sIGj2E1mJoagMAEdCLhvaiC3VMQbRaqJ3x8UDDNddzvVLsOyVEbYE
UpbSIIN9r4Yna0KaGEuK2NC04Of+cRQWkcnBBklxPXWiYCfiYWrdGiap7j+Lcp9x
bCfOOeJyE3K9fOLrBDef2MtOoZhzMt462GIfig3hBbiYDf/C/9PFvFY7LDlbFMfR
1PIcWME8IHWNsZsROjQ5DlzcmVPopyaBQ9mbSQtEDEJqnQtgoyVKu7oBmyuBLaSb
EtRtJS5cly1C+ws+Vt9mlMXj9cM3Vv7Kkqu0wivSG48dT1dUqrj0SHOHfKqYeHRA
mDdHqmr/cXSXz47zLVv9G2pLOwRYh8R7LSSZwutGvYYyAKCqe4xRk9ihHtKCNtg0
ZnasK/8Rt5N22MGmJnhJ
=p9Xv
-----END PGP SIGNATURE-----
Re: t/r 3.0.2
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On 23.09.2011 17:52, Igor Galić wrote:
> > in a long time to do so now. Please cast your votes or concerns
> > for the remaining.
>
> First, 3.0.x as of right now builds fine on my Debian box. However I
> noticed a non critical issue. Regressions checks don't compile on gcc
> 4.6 (once again) in combination with -Werror which is used in default
> builds:
>
> test_atomic.cc: In function ‘int main(int, const char**)’:
> test_atomic.cc:214:7: error: cast to pointer from integer of
> different
> size [-Werror=int-to-pointer-cast]
> cc1plus: all warnings being treated as errors
>
> This does not occur in trunk, as Igor consolidated string functions
> there, which, "by accident" also fixed that compile time issue.
> Probably
> its not desirable to backport the full set of invasive changes to
> 3.0.x
> though.
Patch+Jira:
http://svn.apache.org/viewvc?rev=1171365&view=rev
https://issues.apache.org/jira/browse/TS-969
I added a STATUS entry.
> Also I will probably patch my Debian build with my patch proposed in
> TS-967 due to a compile time build flags transition in Debian which
> passes several CFLAGS now, including but not limited to hardening
> flags.
> I am, however, perfectly fine if that fix is not (yet?) backported to
> a
> 3.0.x stable release.
I haven't had any cycles to review that patch, although it looked very
fine on first sight.
> Finally I was informed by an user in #trafficserver that parent
> caching
> is broken in 3.0, but working in 3.1. I see several related patches
Does that include 3.0.1 or
> in
> trunk which could have caused that that fix - but I am not exactly in
> the position to judge here. Presuming there is a real issue with
> parent
> caching (I can't test right now) that should definitively be
> backported.
Can we track down what exactly is broken and what has fixed it?
https://issues.apache.org/jira/browse/TS-906
http://svn.apache.org/viewvc?view=rev&revision=1154744
Which is proposed only seems to deal with auth. It also seems, and I
only noticed that now, to break ABI compatibility. Or am I mislead here?
> - --
> with kind regards,
> Arno Töll
> IRC: daemonkeeper on Freenode/OFTC
> GnuPG Key-ID: 0x9D80F36D
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: t/r 3.0.2
Posted by Arno Töll <de...@toell.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
On 23.09.2011 17:52, Igor Galić wrote:
> in a long time to do so now. Please cast your votes or concerns
> for the remaining.
First, 3.0.x as of right now builds fine on my Debian box. However I
noticed a non critical issue. Regressions checks don't compile on gcc
4.6 (once again) in combination with -Werror which is used in default
builds:
test_atomic.cc: In function ‘int main(int, const char**)’:
test_atomic.cc:214:7: error: cast to pointer from integer of different
size [-Werror=int-to-pointer-cast]
cc1plus: all warnings being treated as errors
This does not occur in trunk, as Igor consolidated string functions
there, which, "by accident" also fixed that compile time issue. Probably
its not desirable to backport the full set of invasive changes to 3.0.x
though.
Also I will probably patch my Debian build with my patch proposed in
TS-967 due to a compile time build flags transition in Debian which
passes several CFLAGS now, including but not limited to hardening flags.
I am, however, perfectly fine if that fix is not (yet?) backported to a
3.0.x stable release.
Finally I was informed by an user in #trafficserver that parent caching
is broken in 3.0, but working in 3.1. I see several related patches in
trunk which could have caused that that fix - but I am not exactly in
the position to judge here. Presuming there is a real issue with parent
caching (I can't test right now) that should definitively be backported.
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOf0mMAAoJEMcrUe6dgPNt1hEP/AwqdEMWi9ckAYFs8DbpMugi
wgrFidvV0QkTov+pRTkrrQ3k7bN4eFddNF7cXIkOZ1AoDnEBppSSXOuaTP+toBT8
sW9GrT6R2Y1wYI39612yOEWy0mVWJytRyLrpUp1UlTrfBPFaA9vnEfnvjXQkyGmf
iOAlc9QdG51T44iYB3/fIVJQwa6JwrllQUlpehnfEU1+vU9eYpHEkvsv0kb3D+fX
Uqfefe/7CAE1arxvkJ7NZ0UlXHUUsc993oqfbNlfMT/pJt7YUvt7x0BiTJVGuRPW
yD2ASLx5sz/8st77n4CyRMJtB5hoIGXNMi7fzPN+VBAdiR+3X7U68ofpIWompH08
XqfaUeM84F1pZTP2JhY42wNsc+3ealH7/L83lsZLalY+etvgX1s3hfXzQCpDnCBb
1H4pTTTQPF6XaFI31bqDs8GZvoAihaBJS91U9M6e/rsG2rRTbyWaVOanGbqHDxc3
zAh/D4wF70K3UhtwRpQc5Ptp3HEZejYtzU2j1RdXNqV5ZgAi7MtgHrDIfsVNQ2A9
+U4QxBD1L5tuT0jMVkAHsz8oqyygBGai3t6XJ+BgwpXUv2+5jT6pMNrf47m2wKeP
6bW624w58Dp0MK2cpIVO6qiK580wQsZpHO758HG3xGX1tRheYDa1I4N+HVUF/DDz
hAsyRs8Zm0mdXrHPCvEP
=wXFk
-----END PGP SIGNATURE-----