libxmlplusplus-general — Open discusions about libXML++

[libxml++] Node::find() crashes

[<pa...@at...>]

I found the cause of this problem.  The DLL I've made, that uses the libxml++ DLL, was being built with "multi-threaded debug" code generation, when it should have been set for "multi-threaded debug DLL" code generation.

Thanks,

-Brent

Re: [libxml++] get_children

[Jonathan W. <co...@co...>]

On Mon, Jul 18, 2005 at 11:08:21PM +0000, pa...@at... wrote:

> If I have the following document:
> 
> <?xml version="1.0" encoding="utf-8"?>
> <truck id="tip" targ="gamestart">
>   <boat id="menuMatrix">
>   </boat>
>   <state id="start">
>   </state>
> </truck>
> 
> ...and through the document provided by the domparser, I have obtained the root element, then should'nt it be true that a "get_children()" call on that root element would return 2, since the root (e.g. "truck") element has only two sub-elements?  Am I missing something here?  I always get a number several higher than what the document presents for child-elements of the root node.

There are empty text node children of the root as well:

<truck>
 |
 |--text node
 |
 |--<boat>
 |   |
 |   |--text node
 |
 |--text node
 |
 |--<state>
 |   |
 |   |--text node
 |
 |--text node

You can set parser options so that empty text nodes are stripped when
building the dom tree.

regards,

jon

[libxml++] get_children

[<pa...@at...>]

If I have the following document:

<?xml version="1.0" encoding="utf-8"?>
<truck id="tip" targ="gamestart">
  <boat id="menuMatrix">
  </boat>
  <state id="start">
  </state>
</truck>

...and through the document provided by the domparser, I have obtained the root element, then should'nt it be true that a "get_children()" call on that root element would return 2, since the root (e.g. "truck") element has only two sub-elements?  Am I missing something here?  I always get a number several higher than what the document presents for child-elements of the root node.

Thanks,

-Brent

[libxml++] libxml++ crashing

[<pa...@at...>]

I've got a VC++ project that depends on libxml++, and crashes when a vector returned from libxml++ goes out of scope (specifically, I'm referring to the find() routine).  I also noticed that the Element::get_children() call always seems to return a higher number of children, for that context node, than the document actually has.  I'm a little suspicious that the faulty "number of children" reporting is responsible for the destruction of non-existent pointers.  But I don't know.

Anyone else had this problem before?

Thanks,

-Brent

[libxml++] Mac OS X installation

[Chris C. <cq...@Cs...>]

Hi,

Has anyone managed to get libxml++2 installe dand operational on Mac OS 
X 10.4?

I have tried with both darwinports - both libxml++, and libxml++2 fail 
to install.  The former fails with

ld: warning -undefined suppress disables -prebind
ld: warning multiple definitions of symbol ___eprintf
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libgcc.a(_eprintf.o) private 
external definition of ___eprintf in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/libstdc++.dylib(single module) 
definition of ___eprintf
ld: multiple definitions of symbol ___divdi3


and version 2 fails when installing a dependancy xrender


Using fink I managed to get libxml2 installed - however in fink's 
trasitional tree it only uses gcc-3.3 and I get unresolved symbol errors 
when trying to link against libxml++2. (typeinfo symbols from the 
dynamic_casts<>)

Basically, I was wondering if anyone knew how to get this installed on 
Tiger (10.4) using gcc-4.0 as the default compiler.  I have used up all 
my ideas trying to get this installed, any pointers in the right 
direction greatfully recieved!

It is exactly what I want to use - The API etc is just so much nicer 
than xerces...

Cheers
Chris


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [libxml++] XML documents validation & SAX parser

[Daniel V. <vei...@re...>]

On Thu, Jun 23, 2005 at 04:10:10PM -0400, Tomas Pevny wrote:
> Hello,
> I have a question regarding the SAX parser. I have implemented in my code and 
> it works well. The issue is, when I set that I want to validate the document 
> (function parser.set_validate()), it is still parsing the documents, where 
> the DTD is missing. 

  Libxml2 SAX parser has no support for the validation(s) interfaces
[though XML Schemas is about to be added].

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
vei...@re...  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[libxml++] XML documents validation & SAX parser

[Tomas P. <tom...@bi...>]

Hello,
I have a question regarding the SAX parser. I have implemented in my code and 
it works well. The issue is, when I set that I want to validate the document 
(function parser.set_validate()), it is still parsing the documents, where 
the DTD is missing. 
Have anybody an idea, what should be wrong? I have tried the same thing on the 
example code available on the homepage, and the behaviour is the same.
Thanks for any suggestions.
Tomas Pevny

Re: [libxml++] Installation Problemo

[Rupert S. <rup...@li...>]

Collin Scangarella wrote:
> Hey, I have been trying to install libxml++ for a
> while, and i keep having the same problem. Whenever I
> configure it and it checks for glibmm, it cant find
> it, despite how it is installed on my computer. It
> tells me to move a glibmm2.4.pc to my pkg_config_path.
> What? i found that file, now where do i move it to? 
> 
> I am running SuSE 9.3. 
> 
> Thanks,
> Collin
> 
> 
You don't have to move the file. What's probably happening is that your
glibmm2.4.pc was installed into /usr/local (did you install glibmm from
source?), but pkgconfig isn't automatically set up to look in
/usr/local/lib/pkgconfig or wherever the file is.

Fortunately, all you have to do is change the environment variable
PKG_CONFIG_PATH. My ~/.bashrc has:

PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig

And everything works. Good luck!

Rupert

[libxml++] Installation Problemo

[Collin S. <cj...@ya...>]

Hey, I have been trying to install libxml++ for a
while, and i keep having the same problem. Whenever I
configure it and it checks for glibmm, it cant find
it, despite how it is installed on my computer. It
tells me to move a glibmm2.4.pc to my pkg_config_path.
What? i found that file, now where do i move it to? 

I am running SuSE 9.3. 

Thanks,
Collin


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

Re: [libxml++] [patch] Global initialization code

[Christophe de V. <cde...@al...>]

Le Vendredi 17 Juin 2005 10:04, Thomas Jarosch a =E9crit=A0:
> > > > I think so, with the global init doing nothing IF an environnement
> > > > variable "LIBXMLPP_NO_STATIC_INIT" has been defined.
> > >
> > > This still requires recompilation and is therefore not ABI compatible,
> > > IMHO.
> >
> > I think I disagree : the current global initialisation is done by
> > Init::Init. We can, without breaking the ABI, change its behavior so it
> > does nothing when a particular environment variable is set.
> > We can add another class, let's say InitNG, which does what you suggest=
ed
> > for Init.
> > This way people who want to do manual initialisation can do it by setti=
ng
> > this variable.
>
> Sorry, missed the environment part while reading
> as you wrote the french version ;-)

Sorry :-)

> I would take the the environment variable as last option
> because that's not very intuitive for the end user.
> (f.e. program crashes because he/she forget to set it)

I don't think it's a good solution either.

> > Another way I just thought about is not to change Init::Init behavior,
> > but adding both another init class and a free function (probably a stat=
ic
> > function of the new init class) which undo what Init have done and forc=
es
> > it's destructor not to do anything.
> > The advantage is that the proper behavior of the program does not depend
> > on a user intervention.
>
> That would be an option, though it's still messy.

A bit messy, but still better than the environment variable solution (it do=
es=20
not rely on the user, so it's reliable), and not breaking the ABI.
=46or now I don't see another way to achieve your goal not breaking the abi=
 and=20
being reliable.
The only other way would need a specific compilation of libxml++ for your=20
project, which break the ABI.

> Is there a garantuee=20
> from the compiler in which order global objects are created?

Unfortunately no. That would be too easy :-) I know that with gcc we can be=
=20
pretty sure the library global initialisation is done before the main progr=
am=20
one. But we can't rely on it, as other compilers will cause problems.

Regards,

Christophe

Re: [libxml++] [patch] Global initialization code

[Thomas J. <tho...@in...>]

> > > I think so, with the global init doing nothing IF an environnement
> > > variable "LIBXMLPP_NO_STATIC_INIT" has been defined.
> >
> > This still requires recompilation and is therefore not ABI compatible,
> > IMHO.
>
> I think I disagree : the current global initialisation is done by
> Init::Init. We can, without breaking the ABI, change its behavior so it
> does nothing when a particular environment variable is set.
> We can add another class, let's say InitNG, which does what you suggested
> for Init.
> This way people who want to do manual initialisation can do it by setting
> this variable.

Sorry, missed the environment part while reading
as you wrote the french version ;-)

I would take the the environment variable as last option
because that's not very intuitive for the end user.
(f.e. program crashes because he/she forget to set it)

> Another way I just thought about is not to change Init::Init behavior, but
> adding both another init class and a free function (probably a static
> function of the new init class) which undo what Init have done and forces
> it's destructor not to do anything.
> The advantage is that the proper behavior of the program does not depend on
> a user intervention.

That would be an option, though it's still messy. Is there a garantuee
from the compiler in which order global objects are created?

Thomas

Re: [libxml++] [patch] Global initialization code

[Christophe de V. <cde...@al...>]

Good morning,

Le Vendredi 17 Juin 2005 09:39, Thomas Jarosch a =E9crit=A0:
> > > I was typing faster than thinking... doing nothing is not possible
> > > as libxml2 needs to be initialized. IMHO there is no ABI compatible
> > > way of replacing the global initialization code, is there?
> >
> > I think so, with the global init doing nothing IF an environnement
> > variable "LIBXMLPP_NO_STATIC_INIT" has been defined.
>
> This still requires recompilation and is therefore not ABI compatible,
> IMHO.

I think I disagree : the current global initialisation is done by Init::Ini=
t.=20
We can, without breaking the ABI, change its behavior so it does nothing wh=
en=20
a particular environment variable is set.
We can add another class, let's say InitNG, which does what you suggested f=
or=20
Init.
This way people who want to do manual initialisation can do it by setting t=
his=20
variable.

Another way I just thought about is not to change Init::Init behavior, but=
=20
adding both another init class and a free function (probably a static=20
function of the new init class) which undo what Init have done and forces=20
it's destructor not to do anything.
The advantage is that the proper behavior of the program does not depend on=
 a=20
user intervention.

Christophe

Re: [libxml++] [patch] Global initialization code

[Thomas J. <tho...@in...>]

Good morning,

On Friday 17 June 2005 09:34, Christophe de VIENNE wrote:
> > > > >>I implemented the code like I wrote above. And it works :-)
> > > > >>It's not ABI compatible as the new library doesn't contain the
> > > > >> static init object, but it's 100% API compatile. -> It's best to
> > > > >> bumb the .so version for the next release.
> > > > >
> > > > > That would be highly undesirable. ABI compatibility must be
> > > > > maintained until we have a really good reason to break it.
> > > >
> > > > What is holding you back from making the global init object do
> > > > strictly nothing, so its only purpose is to keep ABI compatibility
> > > > and users may or may not use it in their application ?
> > > >
> > > > Then, you are ready to remove it when you have other reasons to break
> > > > ABI compatibility.
> > >
> > > This is a great idea. I'll cook up a new version of the patch the next
> > > days.
> >
> > I was typing faster than thinking... doing nothing is not possible
> > as libxml2 needs to be initialized. IMHO there is no ABI compatible
> > way of replacing the global initialization code, is there?
>
> I think so, with the global init doing nothing IF an environnement variable
> "LIBXMLPP_NO_STATIC_INIT" has been defined.

This still requires recompilation and is therefore not ABI compatible, IMHO.

Cheers,
Thomas

[libxml++] [patch] Global initialization code

[Thomas J. <tho...@in...>]

Christophe,

On Monday 13 June 2005 13:08, Thomas Jarosch wrote:
> > So it looks like a --disable-static-initialisation in the configure
> > script would solve the issue.
> >
> > Any objection ?
>
> Fine with me. Of course we have to add a destructor to the Document::Init
> class and reset the callbacks. The Document::Init constructor needs an
> additional parameter (default: true) if it should call xmlCleanupParser()
> during destruction.
>
> I had another idea:
> Would it be possible to create the global _init object via an include file?
>
> #define LIBXMLPP_DISABLE_STATIC_INIT 1
> #include <libxml++.h>
>
> Multiple applications which use libxml++ could still
> share the same binary library file.

I implemented the code like I wrote above. And it works :-)
It's not ABI compatible as the new library doesn't contain the static init 
object, but it's 100% API compatile. -> It's best to bumb the .so version
for the next release.

Please let me know what you think.

Cheers,
Thomas

Re: [libxml++] Borland C++/C++ Builder

[Darko M. <da...@uv...>]

Christophe de VIENNE wrote:
> That would be nice. If one day you work on doing this with libxml++ 2.10 I'd 
> include it too.

Shall I send makefile to you directly?

Darko

Re: [libxml++] Global initialization code

[Thomas J. <tho...@in...>]

> > > > The problem with the "static" class is that it gets executed
> > > > during library load time. This is why it breaks PHP.
> > >
> > > Do you need it not to be executed at all, or only once ?
> >
> > Only init once and reset after libxm++ code usage.
> > Something like:
> >
> > - libxml::init()
> > - XML manipultions via libxml++
> > - libxml::deinit()
>
> Well, to do libxml::init() and libxml::deinit(), you can simply control a
> Document::Init instance.
> The thing is that you need it not to be default initiated.
> Globally, this solution looks heavy to me, but I don't see a workaround.
>
> So it looks like a --disable-static-initialisation in the configure script
> would solve the issue.
>
> Any objection ?

Fine with me. Of course we have to add a destructor to the Document::Init
class and reset the callbacks. The Document::Init constructor needs an 
additional parameter (default: true) if it should call xmlCleanupParser()
during destruction.

I had another idea:
Would it be possible to create the global _init object via an include file?

#define LIBXMLPP_DISABLE_STATIC_INIT 1
#include <libxml++.h>

Multiple applications which use libxml++ could still
share the same binary library file.

Thomas

Re: [libxml++] Borland C++/C++ Builder

[Christophe de V. <cde...@al...>]

Le Vendredi 10 Juin 2005 14:49, Darko Miletic a =E9crit=A0:
> Christophe de VIENNE wrote:
> > Wouldn't std::string() instead of std::string("") be better ?
> > Anyway this is something we can include in the 1.0 branch.
>
> I guess you are right. And it would be great to include this into 1.0
> branch. Furthermore if you wan't you can include the makefile for
> Borland compiler.

That would be nice. If one day you work on doing this with libxml++ 2.10 I'=
d=20
include it too.

Thanks

Christophe

Re: [libxml++] Global initialization code

[Christophe de V. <cde...@al...>]

Le Lundi 13 Juin 2005 11:33, Thomas Jarosch a =E9crit=A0:
> On Monday 13 June 2005 11:16, Christophe de VIENNE wrote:
> > Le Lundi 13 Juin 2005 10:39, Thomas Jarosch a =E9crit=A0:
> > > > Can you be more precise ? What is broken exactly ?
> > > > It the php xml parser is base on libxml2 and use it's callback (as =
we
> > > > do with libxml++), then I don't think a cohexistence is possible.
> > >
> > > PHP uses libxml2 without those callbacks. As soon as I create a node
> > > using PHP function calls, I end up in libxml++'s callback :o)
> >
> > Wait, is the problem the callbacks themselves ? Are they disturbing the
> > php xml parser ? the thing is that libxml++ cannot work properly without
> > them.
>
> Exactly! The root of the problems seems to be that libxml++ and PHP
> both manipulate the node->_private pointer for their own needs.

Now it's clearer :-)

> > > The problem with the "static" class is that it gets executed
> > > during library load time. This is why it breaks PHP.
> >
> > Do you need it not to be executed at all, or only once ?
>
> Only init once and reset after libxm++ code usage.
> Something like:
>
> - libxml::init()
> - XML manipultions via libxml++
> - libxml::deinit()

Well, to do libxml::init() and libxml::deinit(), you can simply control a=20
Document::Init instance.
The thing is that you need it not to be default initiated.
Globally, this solution looks heavy to me, but I don't see a workaround.

So it looks like a --disable-static-initialisation in the configure script=
=20
would solve the issue.

Any objection ?

Christophe

Re: [libxml++] Global initialization code

[Thomas J. <tho...@in...>]

On Monday 13 June 2005 11:16, Christophe de VIENNE wrote:
> Le Lundi 13 Juin 2005 10:39, Thomas Jarosch a =E9crit=A0:
> > > Can you be more precise ? What is broken exactly ?
> > > It the php xml parser is base on libxml2 and use it's callback (as we
> > > do with libxml++), then I don't think a cohexistence is possible.
> >
> > PHP uses libxml2 without those callbacks. As soon as I create a node
> > using PHP function calls, I end up in libxml++'s callback :o)
>
> Wait, is the problem the callbacks themselves ? Are they disturbing the p=
hp
> xml parser ? the thing is that libxml++ cannot work properly without them.

Exactly! The root of the problems seems to be that libxml++ and PHP
both manipulate the node->_private pointer for their own needs.

> > The problem with the "static" class is that it gets executed
> > during library load time. This is why it breaks PHP.
>
> Do you need it not to be executed at all, or only once ?

Only init once and reset after libxm++ code usage.
Something like:

=2D libxml::init()
=2D XML manipultions via libxml++
=2D libxml::deinit()

Cheers,
Thomas

Re: [libxml++] Global initialization code

[Christophe de V. <cde...@al...>]

Le Lundi 13 Juin 2005 10:39, Thomas Jarosch a =E9crit=A0:

> > Can you be more precise ? What is broken exactly ?
> > It the php xml parser is base on libxml2 and use it's callback (as we do
> > with libxml++), then I don't think a cohexistence is possible.
>
> PHP uses libxml2 without those callbacks. As soon as I create a node using
> PHP function calls, I end up in libxml++'s callback :o)

Wait, is the problem the callbacks themselves ? Are they disturbing the php=
=20
xml parser ? the thing is that libxml++ cannot work properly without them.

>
> The problem with the "static" class is that it gets executed
> during library load time. This is why it breaks PHP.

Do you need it not to be executed at all, or only once ?

Regards

Christophe

Re: [libxml++] Global initialization code

[Christophe de V. <cde...@al...>]

Le Lundi 13 Juin 2005 10:39, Thomas Jarosch a =E9crit=A0:
> Christophe,
>
> I already did and it fixed the problem. Took me hours to debug it
> until I realized what's really happening (PHP just started to segfault).

So it's really the multiple loading of libxml++ then.

> The question is now if there's a more elegant solution
> than having a compile-time option?

I wonder if the nifty-counter idiom can solve this without changing the=20
current behavior, nor breaking the ABI.
The question is, in the case of multiple load of a library, are the interna=
l=20
variable shared by the different instances, or duplicated ?

Regards,

Christophe

Re: [libxml++] Global initialization code

[Thomas J. <tho...@in...>]

Christophe,

On Monday 13 June 2005 10:25, Christophe de VIENNE wrote:
> > Document::Init Document::init_;
> >
> > We use PHP as apache module and have another module linking libxml++.
> > The above piece of code totally breaks PHP's XML parser
> > just by loading the second module.
>
> Can you be more precise ? What is broken exactly ?
> It the php xml parser is base on libxml2 and use it's callback (as we do
> with libxml++), then I don't think a cohexistence is possible.

PHP uses libxml2 without those callbacks. As soon as I create a node using PHP 
function calls, I end up in libxml++'s callback :o)

> > Changing the code is not easy as it would break existing applications.
> > One possible solution would be to add a check to every constructor if the
> > library was already initialized. On the destruction of the last libxml++
> > class if would have to be uninitialized.
>
> It's unclear to me if the problem comes from a double-initialisation of
> libxml++ or a conflit between php and libxml++ which are not able to
> 'share' their use of libxml2.
> Moreover such a test ( checking to every constructor if the library was
> already initialized) is basically what's being done by the static Init
> instance. We could maybe add some checks in the Init constructor but I
> don't see a case where it's needed : static should do it for us.

The problem with the "static" class is that it gets executed
during library load time. This is why it breaks PHP.

> > A more clean way would be to have an init()/deinit() function.
> > Perhaps the use of this mode could be a compile time option?
> >
> > Please let me know what you think about this.
>
> I'm unsure about this. I don't think having a different behavior (ie the
> user being obliged to call the init/deinit functions) based on a
> compile-time option is a good idea. Anyway if the problem really comes from
> here you can try and patch libxml++ to see if it's fixing you problems.

I already did and it fixed the problem. Took me hours to debug it
until I realized what's really happening (PHP just started to segfault).

The question is now if there's a more elegant solution
than having a compile-time option?

Cheers,
Thomas

Re: [libxml++] Global initialization code

[Christophe de V. <cde...@al...>]

Le Dimanche 5 Juin 2005 20:29, Thomas Jarosch a =E9crit=A0:
> Hi,
>

Hi Thomas,

Sorry about the delay...

> libxml++ uses global initialization code like this:
>
> Document::Init::Init()
> {
>    xmlInitParser(); //Not always necessary, but necessary for thread
> safety. xmlRegisterNodeDefault(on_libxml_construct);
>    xmlDeregisterNodeDefault(on_libxml_destruct);
>    xmlThrDefRegisterNodeDefault(on_libxml_construct);
>    xmlThrDefDeregisterNodeDefault(on_libxml_destruct);
> }
>
> Document::Init Document::init_;
>
> We use PHP as apache module and have another module linking libxml++.
> The above piece of code totally breaks PHP's XML parser
> just by loading the second module.

Can you be more precise ? What is broken exactly ?
It the php xml parser is base on libxml2 and use it's callback (as we do wi=
th=20
libxml++), then I don't think a cohexistence is possible.

>
> Changing the code is not easy as it would break existing applications.
> One possible solution would be to add a check to every constructor if the
> library was already initialized. On the destruction of the last libxml++
> class if would have to be uninitialized.

It's unclear to me if the problem comes from a double-initialisation of=20
libxml++ or a conflit between php and libxml++ which are not able to 'share=
'=20
their use of libxml2.
Moreover such a test ( checking to every constructor if the library was=20
already initialized) is basically what's being done by the static Init=20
instance. We could maybe add some checks in the Init constructor but I don'=
t=20
see a case where it's needed : static should do it for us.

> A more clean way would be to have an init()/deinit() function.
> Perhaps the use of this mode could be a compile time option?
>
> Please let me know what you think about this.

I'm unsure about this. I don't think having a different behavior (ie the us=
er=20
being obliged to call the init/deinit functions) based on a compile-time=20
option is a good idea. Anyway if the problem really comes from here you can=
=20
try and patch libxml++ to see if it's fixing you problems.


Regards,

Christophe

Re: [libxml++] Segfault with node->find()

[Christophe de V. <cde...@al...>]

Le Dimanche 12 Juin 2005 23:51, Rupert Swarbrick a =E9crit=A0:
> If I use something like:
>
> xmlpp::NodeSet found;
> const xmlpp::TextNode* node_text;
> found =3D node->find( "./some/valid/path" );
> node_text =3D dynamic_cast<const xmlpp::TextNode*>(found[0]);
>
> Everything is fine.
>
> However, this:
>
> found =3D node->find( "./some/INVALID/path" );
>
> produces a segfault.

I can't reproduce such a behavior. Is the segfault on find itself ? Could y=
ou=20
post a sample code on which you have the problem ?

And about gdb, try to obtain the backtrace.


Regards,

Christophe

[libxml++] Segfault with node->find()

[Rupert S. <rup...@li...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I use something like:

xmlpp::NodeSet found;
const xmlpp::TextNode* node_text;
found = node->find( "./some/valid/path" );
node_text = dynamic_cast<const xmlpp::TextNode*>(found[0]);

Everything is fine.

However, this:

found = node->find( "./some/INVALID/path" );

produces a segfault.

Am I doing something wrong? gdb isn't hugely helpful because I just get
tied up in inlined template functions for vector and there's a segfault
_somewhere_ in them!

Do I need to check beforehand whether there's anything at the end of the
path?

Thanks in advance,

Rupert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQqyuSEbXf6SW2FaGAQIZ8wP/Qv9u79bRRpLaEAhuCYEtCO7+qcOjx2C3
ygRQzNFfSMXajhDA/CFw8ZbC80rAS1AwhYit3JZmXiIsO/dD127xKvC5PPcN8Rr2
ouqgkeZyXXGThm1kayV02L/DX/VBcbnB043Mpp/f/t0YBPUObJXviR5xcywgTBTt
r/CLDsoxoks=
=G9Lo
-----END PGP SIGNATURE-----