Re: [Python-Dev] Importing bsddb 4.6.21; with or without AES encryption?
Gah. I just went and visited the Berkeley DB download site as I was preparing my commit message so I could refer to the exact .tar.gz being imported, only to notice that the latest version is now 4.7.25. Jesus, can we use this version? Trent. ________________________________________ From: python-dev-bounces+tnelson=onresolve.com@python.org [python-dev-bounces+tnelson=onresolve.com@python.org] On Behalf Of Jesus Cea [jcea@jcea.es] Sent: 19 May 2008 23:46 To: Python DEV Subject: Re: [Python-Dev] Importing bsddb 4.6.21; with or without AES encryption? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: | I downloaded the source that includes AES encryption, for no reason | other than it was first on the list. I'm now wondering if we should | only be importing the 'NC' source that doesn't contain any | encryption? Jesus, does pybsddb use any of the Berkeley DB | encryption facilities? Would anything break if we built the | bsddb module without encryption? Yes, pybsddb3 4.6.4 supports cryptography if the underlying Berkeley DB library is crypto enabled. In principle, you can compile BDB without crypto, and pybsddb3 should work, but you would lose ability to open any DB formerly created using page encryption or page checksum. Export laws aside, we better compile with crypto :). Details: http://www.jcea.es/programacion/pybsddb_doc/dbenv.html#set_encrypt <http://www.oracle.com/technology/documentation/berkeley-db/xml/api_c/db_set_...> - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDIDWplgi5GaxT1NAQKaagP+Myn6t364B9cVMUtlKjTIX1LBZkkEG7SX pv+hjUZ68r0Suw8SkhXnBbL2Ek3/yFhvNHH8qAZvEtRGsFGmKiNXccn9Ce3oy0me rAYhuuICleAUJ8RO8FZz+sGK3SR4kITrqnGfMnG46u0rXDQy82NSRW2+uWz/D96d U+X/wfV2HgQ= =io+q -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: | Gah. I just went and visited the Berkeley DB download site as | I was preparing my commit message so I could refer to the | exact .tar.gz being imported, only to notice that the latest | version is now 4.7.25. Jesus, can we use this version? Err.... No. It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. I will comment when I have spend some time with 4.7. Any comment, Greg?. In any case, what would be the procedure to update the buildbot infraestructure?. No, DO NOT update Berkeley DB yet!. I keep a private branch in pybsddb for BDB 4.7 support, waiting for Oracle publication. Since they already pushed 4.7.25 out (no pre warning for bindings developers, too bad!), I think I can publish pybsddb 4.7.0 in a couple of days. That done, I will update python version. PS: pybsddb 4.7.0 will support Berkeley DB 4.0 to 4.7. So, the buildbots don't need to be upgraded.. unless we decide that Python 4.6/3.0 will have Berkeley DB 4.7. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDRmkplgi5GaxT1NAQIGGwP/Rxn2A1TgEfKPU14utLBe2Q9oJlILvusX Fdn69/ZXr4Rk7AiVHrvIkokNxBxnQKMWKykXnZmXAF0Tu75IqbOFuokkE8bu7PG9 yvsPsISbgpFmxrdo1bbJcO4r2ZtsMivw+p5l47GSon9reInl8Dr4cOOG3PayiuSq 9icmszNADCo= =u5Qg -----END PGP SIGNATURE-----
In any case, what would be the procedure to update the buildbot infraestructure?.
You need to import the sources into the Python subversion repository; I understand Trent was about to do that. Then you need to adjust Tools/msi/external.bat to have the slaves export the new version. Regards, Martin
In any case, what would be the procedure to update the buildbot infraestructure?.
You need to import the sources into the Python subversion repository; I understand Trent was about to do that.
Indeed. Where do we stand with regards to svn commit e-mails being sent for 'external'? DB 4.6 is ~16MB... Trent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: | Indeed. Where do we stand with regards to svn commit e-mails | being sent for 'external'? DB 4.6 is ~16MB... I just committed bsddb3 4.7.0. Please install Berkeley DB >=4.7.25. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDWh45lgi5GaxT1NAQLorQQAh3t/waArJtE94d3Fk4YbbxdO9i4+GmMO /xqcT1iHr+qg034LUYxVfWhGdjnbqNj2ZcTjWXEBVqgIqVT5yCYzbDrh0bKmROC0 QjQ0WaMJeMvqj1mGhmDCD3+QAYirUkEg3kAO8icrI9SkTedM6m4EMoT+GI2N6JSI k3SjvOPTKFw= =k2lF -----END PGP SIGNATURE-----
I just committed bsddb3 4.7.0. Please install Berkeley DB >=4.7.25.
Oh my. Just finished plugging 4.7.25 into the Windows build environment. Upon running regrtest.py -v -u bsddb test_bsddb test_bsddb3, I get about 300 lines like this printed to stderr: DB->key_range: method not permitted before handle's open method illegal flag specified to DB->remove Then about 15 lines like this: DB_ENV->rep_start interface requires an environment configured for the replication subsystem DB_ENV->rep_start interface requires an environment configured for the replication subsystem DB_ENV->rep_start interface requires an environment configured for the replication subsystem DB_ENV->rep_start interface requires an environment configured for the replication subsystem Then Python crashes. Quick perusal of stdout reveals this happening on just about every test: ====================================================================== ERROR: test__no_deadlock_first (test.test_bsddb.TestBTree) ---------------------------------------------------------------------- Traceback (most recent call last): File "O:\scm\svn+ssh\pythondev@svn.python.org\python\trunk\lib\test\test_bsddb.py", line 16, in setUp self.f = self.openmethod[0](self.fname, self.openflag, cachesize=32768) File "O:\scm\svn+ssh\pythondev@svn.python.org\python\trunk\lib\bsddb\__init__.py", line 320, in btopen e = _openDBEnv(cachesize) File "O:\scm\svn+ssh\pythondev@svn.python.org\python\trunk\lib\bsddb\__init__.py", line 360, in _openDBEnv e.open('.', db.DB_PRIVATE | db.DB_CREATE | db.DB_THREAD | db.DB_INIT_LOCK | db.DB_INIT_MPOOL) DBInvalidArgError: (22, 'Invalid argument') The last lines before python_d.exe crashes are as follows: testCheckElapsedTime (test.test_bsddb3.TimingCheck) ... ok test_pget (bsddb.test.test_cursor_pget_bug.pget_bugTestCase) ... ERROR testCheckElapsedTime (test.test_bsddb3.TimingCheck) ... ok test01_both (bsddb.test.test_dbobj.dbobjTestCase) ... ERROR test02_dbobj_dict_interface (bsddb.test.test_dbobj.dbobjTestCase) ... ERROR test03_dbobj_type_before_open (bsddb.test.test_dbobj.dbobjTestCase) ... FAIL Think I'll call it a night for now. Trent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote: |> In any case, what would be the procedure to update the buildbot |> infraestructure?. | | You need to import the sources into the Python subversion repository; | I understand Trent was about to do that. | | Then you need to adjust Tools/msi/external.bat to have the slaves export | the new version. I was thinking about the Unix buildbots. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW7/Jlgi5GaxT1NAQL88AP+MXziTzh5wnF6oyjmZtAk9/75LVzHwcjU QyY/MF/DPsL9qnI81Lg7awl4adFaSmntzGX7AAh/TojI40TuW3LI53zFfMAUGsBB q8YaY6zswHENABry+NI8X/mo7J/VeCJstPNANsu1C6o7GSIVH7e6QhzDeOLgsp+O Ae3a1RE+9AU= =m5VB -----END PGP SIGNATURE-----
|> In any case, what would be the procedure to update the buildbot |> infraestructure?. | | You need to import the sources into the Python subversion repository; | I understand Trent was about to do that. | | Then you need to adjust Tools/msi/external.bat to have the slaves export | the new version.
I was thinking about the Unix buildbots.
Ah. There is no way to upgrade them, and attempts to upgrade them should not be made (see my other message) Regards, Martin
Trent Nelson wrote: | Gah. I just went and visited the Berkeley DB download site as | I was preparing my commit message so I could refer to the | exact .tar.gz being imported, only to notice that the latest | version is now 4.7.25. Jesus, can we use this version?
Err.... No.
It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 or 4.7 support. 4.6 has several known issues, apparently solved in 4.7.
I could have sworn I heard a few people mention that "4.5 has issues, but they're solved in 4.6" at PyCon ;-)
I keep a private branch in pybsddb for BDB 4.7 support, waiting for Oracle publication. Since they already pushed 4.7.25 out (no pre warning for bindings developers, too bad!), I think I can publish pybsddb 4.7.0 in a couple of days. That done, I will update python version.
PS: pybsddb 4.7.0 will support Berkeley DB 4.0 to 4.7. So, the buildbots don't need to be upgraded.. unless we decide that Python 4.6/3.0 will have Berkeley DB 4.7.
Seems like the amount of work you have to do has doubled now that you've been added as an svn committer, given that you're maintaining multiple branches of code, one for pybsddb, and one for an official Python branch. I was under the impression that pybsddb would be assimilated into trunk/ Lib/bsddb and become the sole pybsddb incarnation. That is, you'd ditch the separate SourceForge pybsddb project and just work directly in the Python tree. I think I remember reading some concerns you had about doing this last week though, surrounding things like wanting to be able to release pybsddb versions more frequently than Python versions are released. Just because you live in trunk/Lib/bsddb shouldn't prevent you from doing this though; in fact, as long as you're sensitive to major release timeframes, I'm sure we'd love trunk to always track the latest Berkeley DB version; if all the buildbots stay green with 4.7 and there are no regressions in functionality, then hey, lets go with 4.7 for 2.6/3.0. It's probably safe to say that you're the one doing the most work with the code base and Berkeley DB in general, which means you'll be in a much better position to advise us as to which version we should be including or ignoring for a given Python release. In general, if we can support the latest release, we will. If Oracle come out with Berkeley DB 4.8 a week after 2.6 is released, that's fine, we'll keep release26-maint chugging along with 4.7, but we can switch trunk over to 4.8 once you're ready. By the time it's ready to cut 2.7, who knows, trunk's bsddb may be supporting Berkeley DB 5.2 at that stage. I would also think that you could cut independent releases (in the sense that they're not linked to any Python release schedule) of 'pybsddb' from the code living in trunk/Lib/bsddb. That way, users of 2.6 could still easy_install (or whatever) the latest pybsddb 4.8.0 to pick up the newest features. Trent.
On Wed, May 21, 2008 at 5:12 PM, Trent Nelson <tnelson@onresolve.com> wrote:
Trent Nelson wrote: | Gah. I just went and visited the Berkeley DB download site as | I was preparing my commit message so I could refer to the | exact .tar.gz being imported, only to notice that the latest | version is now 4.7.25. Jesus, can we use this version?
Err.... No.
It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 or 4.7 support. 4.6 has several known issues, apparently solved in 4.7.
I could have sworn I heard a few people mention that "4.5 has issues, but they're solved in 4.6" at PyCon ;-)
The line I was giving at PyCon was "4.6 has issues, we might want to stick with 4.5" which is why I left setup.py limiting itself to (4, 5) despite the code being compatible with 4.6. Maybe 4.7 fixes the 4.6 issues; that was a quick release cycle. I haven't given it a whirl at all. I'll try to do that this weekend. But really all I'm doing with it at this point is running the bsddb.db test suite on OS X and Linux and if my build environment is working and I might try that as well. If it passes the entire test suite several times on windows x86 and amd64 builds when built with BerkeleyDB 4.7 (once Jesus commits the support code) I'm inclined to say we should ship with it and only revert back to 4.5 if someone has problems with it during a beta.
I keep a private branch in pybsddb for BDB 4.7 support, waiting for Oracle publication. Since they already pushed 4.7.25 out (no pre warning for bindings developers, too bad!), I think I can publish pybsddb 4.7.0 in a couple of days. That done, I will update python version.
Since 4.7.x is apparently out I suggest going ahead and committing the changes necessary to allow it to build and link against 4.7 regardless of if thats the version we use. No sense in holding back support for compiling. -gps
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory P. Smith wrote: | On Wed, May 21, 2008 at 5:12 PM, Trent Nelson <tnelson@onresolve.com> wrote: |>> Trent Nelson wrote: |>> | Gah. I just went and visited the Berkeley DB download site as |>> | I was preparing my commit message so I could refer to the |>> | exact .tar.gz being imported, only to notice that the latest |>> | version is now 4.7.25. Jesus, can we use this version? |>> |>> Err.... No. |>> |>> It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 |>> or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. |> I could have sworn I heard a few people mention that "4.5 has issues, |> but they're solved in 4.6" at PyCon ;-) | | The line I was giving at PyCon was "4.6 has issues, we might want to | stick with 4.5" which is why I left setup.py limiting itself to (4, 5) | despite the code being compatible with 4.6. I guess we need first all buildbots updated to 4.7.25 before changing the setup.py to support BDB 4.7, to avoid no updated ones linking against (old) buggy 4.6 releases. Reading the buildbot outputs, I see some machines using "ancient" BDB versions. For example, "amd64 gentoo trunk" uses 4.4.x. Would be nice to know the exact release :-). This is interesting, because a buildbot using a DBD < 4.7 will not exercise the module at full capacity, so buildbot value is, somewhat, reduced. For example, testsuite against a 4.0 BDB has 270 tests. Against 4.6, it has 292 test. Now that 4.7.25 is published, pybsddb 4.7.x testsuite will get even bigger, but only when testing against a 4.7 installation!. I would hate to find problems in Python beta releases because the buildbots are outdated :( | If it passes the entire test suite | several times on windows x86 and amd64 builds when built with | BerkeleyDB 4.7 (once Jesus commits the support code) I'm inclined to | say we should ship with it and only revert back to 4.5 if someone has | problems with it during a beta. :-). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW7qplgi5GaxT1NAQLWrwQAk9Xxm5tCB/p4dcCnoWQj3H1rvpJs+c9s g8m/g6+JL8rhlUWixEYApsK53komCGzSC5Ghf91c2QuIQugeGFA4dE3VcYGO89J+ GgvCw+YnJ3KG3DQ2Qw9Lus4LFuDS67bPlSTALQYuLk32ks7FTcTkhNO5qs5JTejs tpQde3MBlLw= =p2qf -----END PGP SIGNATURE-----
I guess we need first all buildbots updated to 4.7.25 before changing the setup.py to support BDB 4.7, to avoid no updated ones linking against (old) buggy 4.6 releases.
Why do you think so? Updating all buildbots is not feasible, atleast not within this year. Some machines *intentionally* stay at old software, just to make sure Python continues to build. Would pybsddb 4.7 continue to build with all bsddb releases that it currently builds with?
Reading the buildbot outputs, I see some machines using "ancient" BDB versions. For example, "amd64 gentoo trunk" uses 4.4.x. Would be nice to know the exact release :-).
Feel free to temporarily commit code to make it find out - either directly in the trunk, or by making a temporary branch and have that branch be built on the particular slave only.
This is interesting, because a buildbot using a DBD < 4.7 will not exercise the module at full capacity, so buildbot value is, somewhat, reduced.
That's a matter of standpoint. It also tests whether the module works and passes its test suite with older releases, which is a good thing. So it's more valuable to have old releases on some slaves, rather than having them test all the same version (which is known to work in principle, anyway).
I would hate to find problems in Python beta releases because the buildbots are outdated :(
Don't worry, some slaves will surely have the latest version, at some point (if none else, the Windows ones will). Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trent Nelson wrote: |> It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 |> or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. | | I could have sworn I heard a few people mention that "4.5 has issues, | but they're solved in 4.6" at PyCon ;-) Or course, it is natural to expect new releases to solve known issues. But initial releases of BDB 4.6 were crappy (current ones are fairly good, even if they didn't patch the "compact()" crash :). I glad to say than pybsddb3 testsuite has catched a few errors in Oracle BDB 4.7 pre-releases, so I'm fairly confident in the final version. | I think I remember reading some concerns you had about doing this last | week though, surrounding things like wanting to be able to release pybsddb | versions more frequently than Python versions are released. Just because | you live in trunk/Lib/bsddb shouldn't prevent you from doing this though; | in fact, as long as you're sensitive to major release timeframes, I'm | sure we'd love trunk to always track the latest Berkeley DB version; This issue is complex and I would like to delay a hard decision until it becomes a real issue. Currently, I rather prefer to keep them apart (but in sync). Aside the frequent release issue (something that would not be an issue when pybsddb3 cover the entire Berkeley DB API, some day), there are mailing lists, community support, open patch submission, etc. I know that merging can be a bit painful. Been there, done that. I'm waiting SVN 1.5 release and its much improved merge repeated merge, like the holy grial :-p. Someday Mercurial could be integrated in Python version control system, and I would sleep better at night. Meanwhile, bsddb patches in the python side are few and apart, and I can cope with them. I want to shield python-dev of this: """ [jcea@tesalia trunk]$ svn diff svn://svn.argo.es/jcea/pybsddb/tags/4.7.0 svn://svn.argo.es/jcea/pybsddb/trunk | wc ~ 1275 3554 37696 """ About ten big commits. And 4.7.0 was released mere hours ago... | if | all the buildbots stay green with 4.7 and there are no regressions in | functionality, then hey, lets go with 4.7 for 2.6/3.0. I will write about this, after you upgrade MS Windows buildbots to 4.7.25. Let's see how it behave. I rather prefer BDB 4.7.25 in Py2.6/3.0 than BDB 4.6.21, unless we discover some ugly bug in last release (as was discovered after 4.6 release; gracefully no python version was released using the faulty lib). I'm using this 4.7.0/4.7.25 release for... uhmm... 20 hours now. No issues so far, in a very BDB busy machine (mailserver, storing user mailboxes via Python->Durus->my durus backend for Berkeley DB->pybsddb3->BDB 4.7.25). A couple of millions emails per day :). | If Oracle come out with Berkeley DB 4.8 a week after 2.6 is released, | that's fine, we'll keep release26-maint chugging along with 4.7, but we | can switch trunk over to 4.8 once you're ready. One of the "problems" with Berkeley DB is that upgrading libraries can require "upgrade" also the database files. The "upgrade" is usually painless, but you can't go back. So, any BDB upgrade in a python release must be clearly marked, because it can become a no-return-point for some users. In Unix world, Python releases would use BDB installed in the system. So, the user/admin has control over BDB upgrades. But since MS Windows Python bundles BDB, we need to be extra-careful there. Someday we need to talk about pybsddb3 "eggs" (via pypi) supporting BDB DLL bundled by stock python in MS Windows. Current approach needs a new DLL. Some *other* day. So much to do, so little time... :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDW1rplgi5GaxT1NAQJEpQP+IFcmL+0zqg1n8MrtyvPiRZk4oBSlwUzD Ov0SHVmx8MmhKk5NOI3FjpKSVZIVU55HZ+qFBuqz12VeYOucZOUeDlsE5LFnmXsC E4HR6+NCi7zHSOyESjy6j6M3rNPWqNiPOUnJ5kevDOcnoA+W8urdj97wHflArsJ3 e1M1R04UoMI= =lisl -----END PGP SIGNATURE-----
participants (4)
-
"Martin v. Löwis" -
Gregory P. Smith -
Jesus Cea -
Trent Nelson