[sword-devel] Changing #include structure (was: I implore you...)

Jaak Ristioja jaak at ristioja.ee
Thu Jun 13 01:47:45 MST 2013 

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

Troy,

Imho there are already header files which clash, namely the zlib ones:

 $ `echo -n 'ls -ld '; find include/ -name '*.h' | sed -e
's_^include/_/usr/include/_'` 2>/dev/null
- -rw-r--r-- 1 root root 15292 sept  24  2012 /usr/include/zconf.h
- -rw-r--r-- 1 root root 87011 sept  24  2012 /usr/include/zlib.h

Jaak


On 13.06.2013 11:32, Troy A. Griffitts wrote:
> Jaak,
> 
> On 06/13/2013 10:12 AM, Jaak Ristioja wrote: Troy,
> 
> It still seems that you missed one thing. Namely, the #includes
> with <> still include a prefix, i.e. sound/ and omniORB4/. The
> Sword #includes do not, and this by itself is a big problem which
> makes header filename clashes a lot more probable, especially if
> other libraries would follow suit and have the same #include
> convention as Sword does.
>> Jaak,  I didn't miss this.
> 
>> As I said in my last email, I'm not saying your wrong.  I'm just
>> saying:
> 
>> a) the headers I looked at include things DIFFERENTLY than your
>> patch, so I'm not sure your fix is the most standard. b) things
>> work right now on a ton of platforms and compilers and build 
>> projects, and I don't want to change this just before a release,
>> which could potential break all of these-- especially if there
>> are no known problems with this right now.  There is no reason to
>> push a potentially disruptive patch just before a release.
> 
>> Also, if you use pkg-config to get the compile and link
>> directives, you shouldn't need to care about what to pass to the
>> compiler.
> 
>> .cpp: g++ `pkg-config --cflags sword` $< -o $@ `pkg-config --libs
>> sword`
> 
> 
>> Thanks for being concerned.  I understand your concern and value
>> your input, Troy
> 
> 
> 
> Regarding <> and "", the latter provides a better safeguard
> against including the wrong headers in some situations, especially
> when dealing with multiple versions of the headers being installed
> at the same time. More commonly, using "" instead of <> can also
> help to simplify the build system for libraries such as Sword.
> 
> I don't consider using <> instead of "" a bug. But what I think is 
> very inconvenient is that one has to explicitly use 
> -I/usr/include/sword/ instead of just using #include
> <sword/stuff.h> in the source files.
> 
> This is cause for confusion for developers, who might think (as I
> did and do): 1) Do I need to #include <stuff.h> // Sword header ? 
> 2) If I #include <sword/stuff.h> then why do I need to pass an
> extra -I argument to the compiler?
> 
> What I'm asking is that even if you don't want "" instead of <>, 
> please use a sword/ prefix for all respective #includes in all
> header files of Sword.
> 
> Blessings, Jaak
> 
> 
> On 13.06.2013 09:47, Troy A. Griffitts wrote:
>>>> Jaak,
>>>> 
>>>> I'm of the same mind as Greg.  Our include syntax has been
>>>> working as is for 20 years on a number of compilers and
>>>> platforms.  I hesitate to wholesale change this now because
>>>> of 'in principle' arguments without any actual problems being
>>>> seen.  I don't have time to compile your changes on all the
>>>> platforms we support to test them.  I know what we have now
>>>> works.
>>>> 
>>>> I'm not saying that you're not right, but I also don't see
>>>> your changes as standard.  Just a brief look on my box, 
>>>> /usr/include/sound/sfnt_info.h includes 
>>>> /usr/include/sound/asound.h with: #include <sound/asound.h>
>>>> 
>>>> /usr/include/omniORB4/anyStream.h includes 
>>>> /usr/include/omniORB4/omniTypedefs.hh with: #include 
>>>> <omniORB4/omniTypedefs.hh>
>>>> 
>>>> Just the first 2 I looked at.
>>>> 
>>>> I'd like more time to investigate this before making a
>>>> change,
>>>> 
>>>> Troy
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 06/12/2013 10:28 PM, Jaak Ristioja wrote:
>>>>> Well, using -I/usr/include/sword is just an ugly
>>>>> workaround. It doesn't change the fact that Sword headers
>>>>> include each other in a wrong manner (using <> instead of
>>>>> ""). Because it would only be a workaround, we do not want
>>>>> to stick to it forever. We want this fixed.
>>>>> 
>>>>> Secondly, headers in the Sword include directory have a
>>>>> greater chance of colluding with other headers in
>>>>> /usr/include/ and elsewhere. Hence the Sword headers
>>>>> themselves might include wrong header files if that
>>>>> happens. That's why using "" instead of <> is important so
>>>>> that relative paths would be searched before any locations
>>>>> specified by -I arguments to the compiler.
>>>>> 
>>>>> I don't believe my patch broke anything, the main changes
>>>>> were substituting <> with "" when #including Sword headers.
>>>>> However, if it did break anything, it should be easy to
>>>>> amend. I'm highly motivated to get my patches applied to
>>>>> the next version of Sword one way or the other. So just ask
>>>>> and I'll fix it.
>>>>> 
>>>>> Blessings, Jaak
>>>>> 
>>>>> 
>>>>> On 12.06.2013 23:05, Greg Hellings wrote:
>>>>>> 
>>>>>> On Wed, Jun 12, 2013 at 2:51 PM, Jaak Ristioja 
>>>>>> <jaak at ristioja.ee <mailto:jaak at ristioja.ee>> wrote:
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> What's the integration status on this patch?
>>>>>> 
>>>>>> Blessings, Jaak
>>>>>> 
>>>>>> 
>>>>>>> Can we allow changes which are not bare-minimum 
>>>>>>> build-breakers, such as restructuring the includes, be
>>>>>>> a later issue for the next next release and just get
>>>>>>> 1.7.0 out the door, please? Also, what prevents you
>>>>>>> from having -I/usr/include -I/usr/include/sowrd and
>>>>>>> then having #include <sword/foo.h> and having it all
>>>>>>> work just as planned? --Greg
>>>>>> 
>>>>>> PS: Is Troy the only one with access to apply this?
>>>>>> 
>>>>>> On 10.06.2013 22:49, Jaak Ristioja wrote:
>>>>>>> Argh, someone must have changed things on SVN lately,
>>>>>>> so this patch was invalid for the current trunk... I
>>>>>>> wish you guys would learn git or something. Anyway,
>>>>>>> here's something which should apply to SVN 2819, I
>>>>>>> hope. SHA1SUM: 071a4fb64f1d0c2ed5d746d08791592f76eaf633
>>>>>>> Blessings, Jaak On 10.06.2013 22:34, Jaak Ristioja
>>>>>>> wrote:
>>>>>>>> Attached is a patch for this. Please apply. SHA1SUM: 
>>>>>>>> 9a99e34ce419ea3288a32148d431ec971fb0e675 Blessings,
>>>>>>>> Jaak On 10.06.2013 19:38, Jaak Ristioja wrote:
>>>>>>>>> I'm working on the patch but here's a short
>>>>>>>>> overview of the problem, in case discussion is
>>>>>>>>> required. The problem is that source code using
>>>>>>>>> Sword can't do stuff like: #include
>>>>>>>>> <sword/versekey.h> This is VERY BAD, because we 
>>>>>>>>> must do #include <versekey.h> and provide 
>>>>>>>>> -I/path/to/sword/includes/ to the compiler every
>>>>>>>>> time. The problem with this approach is that
>>>>>>>>> versekey.h might also exist in /usr/include or in
>>>>>>>>> other -I/include/paths. Additionally, this makes
>>>>>>>>> the #include list rather incomprehensible,
>>>>>>>>> especially when we want to sort it alphabetically.
>>>>>>>>> There's no telling what <versekey.h> refers to - is
>>>>>>>>> it part of Sword, part of something else, or a typo
>>>>>>>>> (e.g. maybe this needs to be "versekey.h"). Why
>>>>>>>>> #includes like <sword/versekey.h> don't work is
>>>>>>>>> that the Sword headers themselves use includes
>>>>>>>>> like <versekey.h> instead of "versekey.h" which is
>>>>>>>>> correct. If I don't include -I/usr/include/sword in
>>>>>>>>> my compiler arguments, but #include
>>>>>>>>> <sword/versekey.h>, the versekey.h file tries to
>>>>>>>>> #include <swkey.h> which fails because it can't
>>>>>>>>> find the file in in the include path. The *.cpp
>>>>>>>>> files in Sword also need to use "" instead of <> to
>>>>>>>>> distinguish between header system and local header 
>>>>>>>>> files. Afaik this is just best practice. Existing
>>>>>>>>> code using #include <versekey.h> etc will continue
>>>>>>>>> to work as long as the -I/path/to/sword/includes
>>>>>>>>> exists. Blessings, Jaak On 10.06.2013 19:21, Jaak
>>>>>>>>> Ristioja wrote:
>>>>>>>>>> Actually I just remembered another serious flaw
>>>>>>>>>> which causes a headache for developers using
>>>>>>>>>> Sword. I'll write a patch ASAP. Blessings, Jaak
>>>>>>>>>> On 10.06.2013 09:43, Troy A. Griffitts wrote:
>>>>>>>>>>> Jaak,
>>>>>>>>>>> 
>>>>>>>>>>> I accepted and applied your header file patch
>>>>>>>>>>> nearly 5 months ago.  Are you telling me that
>>>>>>>>>>> you still have 549 warnings from SWORD
>>>>>>>>>>> headers?
>>>>>>>>>>> 
>>>>>>>>>>> Troy
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 06/09/2013 11:55 PM, Jaak Ristioja wrote:
>>>>>>>>>>> On 09.06.2013 23:21, Troy A. Griffitts wrote:
>>>>>>>>>>>>>> I don't think other developers are
>>>>>>>>>>>>>> getting ignored. Please be specific.
>>>>>>>>>>>>>> Just because I don't accept a patch
>>>>>>>>>>>>>> doesn't mean a developer is getting
>>>>>>>>>>>>>> ignored.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> In fact, many times trying to make this 
>>>>>>>>>>>>>> release, when people complain that we
>>>>>>>>>>>>>> need something fixed for this release, I
>>>>>>>>>>>>>> ask for a simple testsuite addition to
>>>>>>>>>>>>>> show the problem and desired result, and
>>>>>>>>>>>>>> don't get a response.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I don't believe the problem is as you
>>>>>>>>>>>>>> think it is Jaak. Many people whine about
>>>>>>>>>>>>>> this or that. Not all whine for things to
>>>>>>>>>>>>>> go in the same direction.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Everyone whines for a release but not
>>>>>>>>>>>>>> everyone is willing to help submit tests
>>>>>>>>>>>>>> and then fixes for those tests.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You stated that you would get involved
>>>>>>>>>>>>>> to help, but you only submit things for
>>>>>>>>>>>>>> which I previously told you I wasn't
>>>>>>>>>>>>>> interested in accepting (worrying about
>>>>>>>>>>>>>> pedantic warnings whose changes often
>>>>>>>>>>>>>> make the code less readable and do
>>>>>>>>>>>>>> nothing to improve any of the real
>>>>>>>>>>>>>> problems for the end user.  Though I do 
>>>>>>>>>>>>>> appreciate a few of the warning fixes
>>>>>>>>>>>>>> you submitted, a few being actual bug
>>>>>>>>>>>>>> fixed too (thank you)-- I'm just ranting
>>>>>>>>>>>>>> right now.)
>>>>>>>>>>> As a BibleTime developer, I want to available
>>>>>>>>>>> tools (-Wall, -Wextra, cppcheck, etc) to fix
>>>>>>>>>>> any errors in my code. Due to the Sword header
>>>>>>>>>>> files which generate a lot of warnings this
>>>>>>>>>>> task is VERY inconvenient. For example, when I
>>>>>>>>>>> compile the whole of BibleTime with GCC, I get
>>>>>>>>>>> 549 warnings from Sword headers (mostly for
>>>>>>>>>>> unused arguments) - how am I supposed to find
>>>>>>>>>>> the warnings relevant for BibleTime? This alone
>>>>>>>>>>> often makes it a pain to develop BibleTime and
>>>>>>>>>>> gives me enough reason to want to fork Sword.
>>>>>>>>>>> 
>>>>>>>>>>> Turning on and fixing pedantic warnings will
>>>>>>>>>>> help find real bugs. FACT! Forcing developers
>>>>>>>>>>> to work blindfolded will not help anyone.
>>>>>>>>>>> 
>>>>>>>>>>> The same tools can be used to find bugs in
>>>>>>>>>>> Sword code, and SHOULD regularly be used for
>>>>>>>>>>> this purpose to ensure code quality. As is
>>>>>>>>>>> obvious these are currently NOT BEING USED by
>>>>>>>>>>> Sword developers. However, when things
>>>>>>>>>>> eventually break, users complain to the
>>>>>>>>>>> BibleTime project. Hence, it is also in the
>>>>>>>>>>> interests of front-ends to ensure that the code
>>>>>>>>>>> of Sword is of good quality. Again - if Sword 
>>>>>>>>>>> won't work to ensure this and wont let us in to
>>>>>>>>>>> fix things, we have another reason to fork.
>>>>>>>>>>> 
>>>>>>>>>>> This again leads us to the issue of attracting
>>>>>>>>>>> new developers to Sword. I don't want to write
>>>>>>>>>>> on this more than necessary to provide a small
>>>>>>>>>>> argument for my conclusion. Afaik the current
>>>>>>>>>>> situation isn't working well. Biggest obstacles
>>>>>>>>>>> for me personally include working blindfolded,
>>>>>>>>>>> submitting patches by e-mail and not getting
>>>>>>>>>>> enough feedback for (ignored) patches and other
>>>>>>>>>>> emails.
>>>>>>>>>>> 
>>>>>>>>>>> To conclude - maybe its just me, but altogether
>>>>>>>>>>> I really feel it were easier to maintain a
>>>>>>>>>>> parallel fork (at minimal to provide set of
>>>>>>>>>>> patches) than to waste my time writing long
>>>>>>>>>>> letters trying to make this relationship work
>>>>>>>>>>> in its current form. I accept whatever path the
>>>>>>>>>>> Sword project takes, but if it's not enough for
>>>>>>>>>>> the needs of BibleTime and our devs, we will
>>>>>>>>>>> make our own choices as well.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Blessings, Jaak The BibleTime team
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> PS: I apologize if this late-night response is 
>>>>>>>>>>> incomprehensible.
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>
>>>>>>>>>>>> 
sword-devel mailing list:
>>>>>>>>>>>> sword-devel at crosswire.org
>>>>>> <mailto:sword-devel at crosswire.org>
>>>>>>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>
>>>>>>>>>>>> 
Instructions to unsubscribe/change your settings at above
>>>>>>>>>>>> page
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>
>>>>>>>>>>> 
sword-devel mailing list: sword-devel at crosswire.org
>>>>>> <mailto:sword-devel at crosswire.org>
>>>>>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>
>>>>>>>>>>> 
Instructions to unsubscribe/change your settings at above
>>>>>>>>>>> page
>>>>>> 
>>>>>> 
>>>>>>>>>> _______________________________________________ 
>>>>>>>>>> sword-devel mailing list:
>>>>>>>>>> sword-devel at crosswire.org
>>>>>> <mailto:sword-devel at crosswire.org>
>>>>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>>>
>>>>>>>>>> 
Instructions to unsubscribe/change your settings at
>>>>>>>>>> above page
>>>>>> 
>>>>>>>>> _______________________________________________ 
>>>>>>>>> sword-devel mailing list:
>>>>>>>>> sword-devel at crosswire.org
>>>>>> <mailto:sword-devel at crosswire.org>
>>>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>>
>>>>>>>>> 
Instructions to unsubscribe/change your settings at
>>>>>>>>> above page
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>> <mailto:sword-devel at crosswire.org>
>>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>
>>>>>>>> 
Instructions to unsubscribe/change your settings at above
>>>>>>>> page
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> sword-devel mailing list: sword-devel at crosswire.org 
>>>>>>> <mailto:sword-devel at crosswire.org> 
>>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>>>>>>> Instructions to unsubscribe/change your settings at
>>>>>>> above page
>>>>>> 
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel at crosswire.org 
>>>>>> <mailto:sword-devel at crosswire.org> 
>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>>>>>> Instructions to unsubscribe/change your settings at above
>>>>>> page
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel at crosswire.org 
>>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>>>>>> Instructions to unsubscribe/change your settings at above
>>>>>> page
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.org 
>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>>>>> Instructions to unsubscribe/change your settings at above
>>>>> page
>>>> 
>>>> 
>>>> _______________________________________________ sword-devel 
>>>> mailing list: sword-devel at crosswire.org 
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above
>>>> page
>>>> 
>> 
>> _______________________________________________ sword-devel
>> mailing list: sword-devel at crosswire.org 
>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> _______________________________________________ sword-devel mailing
> list: sword-devel at crosswire.org 
> http://www.crosswire.org/mailman/listinfo/sword-devel Instructions
> to unsubscribe/change your settings at above page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQgcBAEBAgAGBQJRuYcrAAoJEEqsYmEt1rCO2dBAAJmo5vimBUbV9Oj8eA6QOvR3
kj79xjqsWouPTuoV5fv5oYqO8KH3S03IzTIR5NjjYQ0gBJSstIE2bfvAwlUnTzkq
5+6/ZQiqLyK1mpMn/Hs1ykze5eV6bKz+bM+9gY2PvI/ftTiPf5inob9iLdU+pv0Z
mh6SGgkv21F3o0S/rWIxGEQM4em59IEbjYqxwniHnq8Icmr3ln2xbu3AObZziAVS
qLg/PHQaYrL1P6E7YetynO4gWqFAqFb5vK/7Jd55qsYLP2XdAP2nUUD5ftMBkils
WFbFZgj3G+6zfQdCo385WROzc6++AUGqXHsFvg0FvpHn5bDQ+66JiifSaykibU9G
cZerJ9yFWB6CyX+E1L7FTsZKkf4RHzwmv86OCXiJAJhECfHAnyKFK4Dp+2Z3oVNw
ME6e4DTmJuPQOEUI4BF2o5rd2HzxxzRZzonzkrpfXkH0DbRJNuZqL6xQVX3Eefen
hCENogvrBT9ZKG1Uq24denYJMSXLaS3JI2il4SruTMGML/ODvUnQ5uTPkoxUICJt
/e/El7vIPwIxLbNOTDiSg+d80c7Uo7Ro3tWOGkN0Qw640arLf11RFu1qeALJRHqK
Wsew6bZzpRZ1U07XXLLAakkIdCfxMW7xfaV4vouSOn5oxROK2I4joFdat1N/ykAD
/7y4uGk8Zbz2/X4gfl84rDvfDo73TVxTrHcVREmwIc2JKP7YUR5k1FOBbEt7y3jd
9p17l/D8SzIkFdKF+/0hsz0o4rSJIQqD5AByPihDtQ3ECIwxtcC9q/xD8RbzL4cg
B2QDJ5xUI1v2nWmQNzXn2RH5zYKARQWlmLJEwiyQA1DPk+U8TewRY/4dBU7C2JAA
E5KhC4lbB8sbBWj3o/qqs4MWXDfBgHI3jHjH5+0UVQj/ucSI/8uSVasy/LU16g4Y
PUbqDC9fNh/JtINj0Yi3IRnpg8et6Jdiy1kuzcPhVUne9er3Yd9VqywNS/uB1sMF
mNU3T+nXdkR8MnK7XQ0eCN3UPVj2Nk7+m+9PqY05agVWQSUxuwYt9gApiLZYIfJg
sTPKtx+uGQqJ4abRrGN9DGdM6bEG7rT1xG0CduJDwWrPHXv/AvXeGiZh4Qhs4jG4
6na7BY+yR1UpCHj9N8Qj3IS69BVmB63TMfEts135i4tChX0HIHi4fdNuhKcoK5pe
7hfEgD6D5rQKtbb5x1w9RlDUddeh/4ksuxo2/QFGPliKr5VhEsthUF3HS+IF4jRE
bdHZQyBjSbNITKMwTCyQt/pVeypBf7ZiNB7z6TbflDA1riwgQOuHCrkOi+t2BiK6
WQvm2GkEYn0ePQQVSlt87srYZw1NCLjoNkU2pVDfMGdtmSsUAXgP5UqgCDbO+gFP
61zwWYr4GJ3CiYThgtZifybTN3efL4eQyNNLgziPrgKqE85D4KEI5F5C9cU32c+k
vLrjBQgx2ss6ICsaCoDrFpoqfqQFhTYK8FYRJileigWR7sBislhnP/MM/4QGUiOu
A1GaaJNuu1aHrqB5+ff3LtdOg37BaZmB6tdjOxV3nrRADL+rEm3FBiU+9sbTartd
qckR/xTHYq9nBJ+BgYCgeq7O6U40AItLFE9WTWIFsGAU6Ve4FrDwYQa67syYtEkN
byQpgD9/hg5fKeMbYZcmEmNPcdb99cLc43qUVv3UcavzbJhV+iuefLTSUpoUqOOa
N02MmnT0y0iEPYxFeWTnXu4gmgv0FH9SuPPa8riwXaBnPEkSrhOaztApJAIj+d2M
ZAXalwIHK3wd6k2S9dTysCKIqfv4THAbZoVPkG49f0ThN5E5hzsgfVsZX8wbqbPk
qp/nl3/BYMeuddHtqzJYapJ4FJvB0g119MhnBz0bnXLWOlXJpborni39CjwSEZqz
cfFep3DHISyo2uQ1GqSn1qKAU9h3mMBAtfNQofQsZ3rKoXVtllhPG85bHBS7MupD
MxrxQtKIQLxS0xF2eeUg86bjzX7aP/ojoNuliGsV2AXO2DAbu/EVHPMJofI6mY7R
qdpg6hGTldIPI3smkFJKEL57f9O1rVsegmGIJoTloDX/qOXQg6D74C3tG6hST64v
B5dNGLF/h+PQAcC7TTiBPkIOPVzjXiqyup2zsqkIwCkWKYOHXTbUXr5yDVdKFEiB
cTsTa5DUlRbMJPfb9LCdcnHzkUCmukYBDtZA1omBIFP2B5kaZ9oosjVuYqMiJqfw
xbVW2JZCOcUkGG31wE5xYEFJkCCfDH+KJ3O2TEsS+af2I9D8mDYZY1sEzOuEJZ88
EW1N1VuxMyXzlhvahjnEr2mjsdYGVdC8bI4tBGjLBcrZ1AEKJItcpYhvugOJkTo4
hXHcWyz5IfOGfw8Yv4cFRKwUCcUztv5wmu8ZI0dXeaIGFphwelF/dwCiPcyN9FwF
fRudqSds6crUmMt3zgHHTzL35HYzh5UOZocGzCkW0Q1O+z6CaY80xUQOrJIvkU9l
8IUL7ePRsNDz3ZPMJaYvnVFHdmi5Y29Y9+GfyNsoSoyfhtbWoIqGWTt4OYazUBGu
1YQ3lum2Fix6ZjLI3THXUJhzfUt2rL76n+ulk8G3W88iDXHHvYoN7yWSx28bWBBp
pJmiiBWKa5p1ESADG3LXQ2sdDKpCrDpUaSbf2rf/gJGvomgcfKVxd8cJ4PfJYIsZ
j6YFDUOqnGf1/YnQo7GZ55AgLok2DQRTBkIFJbZiElkG7rwHEa6awUaftoT0m171
/Si9mQmShWYoKvkbUWsP
=jSzY
-----END PGP SIGNATURE-----

More information about the sword-devel mailing list