CID/PreviousResources

Resources

Delivery / Packaging

  • Unofficial X-PEP Project on GitHub.
  • Unofficial X-PEP Project on GitLAB.
  • GIT Repos on Foundation Gitea.

  • MacPorts recipes for deps and pEp JSON Mini Desktop Adapter (libetpan-fdik, engine, libpepa aka libpEpAdapter)
  • Homebrew formulas for deps and pEp JSON Mini Desktop Adapter
    • “VirtualBrew” (abandoned) to build with Homebrew for legacy macOS
  • JNI_Sequoia_(…).sh scripts, for manually compiling Sequoia-based JNI Adapters Linux on CentOS 6, and on macOS for macOS 10.11 and up. These scripts use CLANG, not GCC even on Linux, as some parts of Sequoia FFI were/are CLANG-only.
  • Python scripts to test JSON adapter Package in a sandbox, in python-wrapper branch in https://pep.foundation/dev/repos/pEpJSONServerAdapter/file/python-wrapper/packaging

JSON and JNI Adapters have been served over the unofficial https://software.pep.foundation server. It hosts static files, and a dynamic webapp which serves the adapter in the way Enigmail requires it (example call).

For technical reasons, the software.pep.foundation site also hosts Git and Mercurial repos:

Integration

  • How a JSON Desktop Adapter User (Client) is searching for the JSON interface: https://software.pep.foundation/pep/pep-json-interface.svg (DRAFT). This needs to be built into “unit tests” at integration level.

  • There is an endless discussion about PER_MACHINE_DIRECTORY and PER_MACHINE_DIRECTORY in Engine release builds going on (ENGINE-524, ENGINE-724 etc), which greatly limits what is possible: we probably need to ship “test” releases (next to debug and release builds) to be able to test release-builds under debug conditions.

Misc

A packaged yml2

Discussions

Building from tarballs vs from repositories

Releases usually require minimally patching the sources. That is, we need to maintain small patches which usually change from release to release.

Moreover, “the repositories” usually contain source code which needs postprocessing with platform-limited tools before being used in general (“source distribution”).

That’s why we should not generally pull from repositories, but from released tarballs.

Even where we’re triggered from repository commits, the dependencies should come from tarballs. Ideally they’re related to tags.