palm/palm365-mac: new port

[HodsonTech]

Summary

As far as I'm aware, this is the first bidirectional sync bridge between a Palm OS PDA and Microsoft 365 that exists anywhere — nobody else has built this. palm365-mac is a jpilot plugin (palm/palm365-mac) that syncs a physical Palm's calendar, tasks, and contacts with a Microsoft 365 account, automatically, every time you HotSync — no manual sync command needed day to day.

That novelty is the actual case for including it despite one real wrinkle noted below: there's genuinely nothing else that does this, for a device class MacPorts already supports well (jpilot, pilot-link).

The one thing worth flagging up front

This port requires a one-time Microsoft 365 app registration per user — a real Microsoft requirement (not something this port could bypass), needed so the tool can read/write your own calendar/contacts/tasks under your own Azure app, not a shared/published one. setup.py (installed to ${prefix}/share/palm365-mac/setup.py) walks through it step by step, and the port's notes {} block tells the user to run it right after install. I'm calling this out explicitly rather than hoping it goes unnoticed in review — happy to adjust anything about how it's presented if that helps.

How it works

• jpilot-plugin/palm365plugin.c (GPLv2, built against jpilot's own GPL plugin-API headers, vendored in jpilot-plugin/vendor/) hooks plugin_startup/plugin_post_sync and hands off to a Python daemon in the background (jpilot's own sync loop calls plugin_post_sync synchronously, so it can't block on network calls).
• The Python side (MIT-licensed, doesn't link against jpilot) talks to Microsoft Graph and reads/writes jpilot's .pdb files via pilot-link's libpisock through ctypes — no C extension needed.
• No hardcoded per-user values anywhere: the plugin derives a stable per-device identity at runtime from jpilot's own base_dir (so multi-device setups work with zero configuration), and all per-user state (config, id-maps, backups) lives under ~/.palm365/, never inside the port's own install tree.

Testing performed

Tested via repeated local port -d install cycles (not just manual compile/install) against a real MacPorts install, including several real-hardware round trips: launching jpilot, a genuine HotSync, and confirming the plugin's automatic push-up/down-sync cycle behaves correctly. Iterating through that process caught and fixed several real packaging bugs before this submission (wrong github.tarball_from mode, a stale unregistered file blocking activation, the plugin's log/config paths defaulting to the shared install directory instead of user-writable space, and setup.py's own printed instructions naming the wrong Python interpreter) — full history in the HodsonTech/palm365-mac commit log if useful context for review.

[HodsonTech]

Update: this now depends on a new companion package, py314-palm-sync-core (submitted in a separate PR shortly), which holds the actual Palm-side reconciliation engine so it can be shared with a Google-backed provider package I'm building next, instead of duplicating that logic. This port now only carries the Microsoft-Graph-specific code.

Also added conflicts palmgoogle-mac (forward-looking) -- two independent full-rebuild sync engines running against the same Palm device at once is a real hazard, not a supported configuration, so provider packages are mutually exclusive by design, enforced by MacPorts itself rather than just documented.

Bumped to v1.5, which includes a real bug caught live during this refactor's own testing: the plugin's device-identity logic was reading jpilot's own compile-time install prefix, not any actual per-device value (traced to jpilot's own source, not guessed). Re-tested the same way as the original submission -- local port -d install cycles plus a full real HotSync round-trip.