Integrate EteSync into Phosh / Plasma Mobile on postmarketOS
EteSync is a free software server and protocol, which provides end-to-end encrypted calendar and contact synchronization.
This would be a good improvement over existing caldav/carddav providers, as those only encrypt the connection to the server, but do not encrypt the actual contents of the calendar / contacts data.
Let's package it for Alpine and create guides for the postmarketOS wiki on how to use it with Phosh and Plasma Mobile. In theory, we would need to package etesync-dav as caldav/carddav "adapter" and then add that in Phosh (GNOME online accounts) / Plasma Mobile.
Activity
added help wanted + 1 deleted label
mentioned in issue #772 (closed)
By Oliver Smith on 2020-09-10T11:43:01
EteSync developer here: I just saw this link and wanted to share some relevant information. EteSync is now support natively in both KDE (Akonadi) and GNOME (EDS backend). So there's no longer any need for etesync-dav or any adapters. Can just add the accounts to GNOME online accounts directly!
By tasn on 2020-12-07T14:11:03
Edited by Administrator-
Great news @tasn, thanks for sharing!
New TODOs for this issue:
-
Package etesync
-
For GNOME: package evolution-etesync
-
For KDE: see kdepim-runtime:
By Oliver Smith on 2020-12-07T14:09:38
-
-
Ahhh, I used the wrong link for the GNOME one, sorry! GNOME link is: https://gitlab.gnome.org/GNOME/evolution-etesync/ (also fixed my original comment).
As for the common EteSync library, it's called libetebase and this is the repo: https://github.com/etesync/libetebase
Here is the Arch Linux package spec if you need some inspiration. Though it's mostly just
make && make install.By tasn on 2020-12-07T14:13:44
-
I have tried packaging libetebase however have hit issues with compiling (only have tried for aarch64). When just running
make, thecargo build --releasestep fails when compiling openssl-sys, it seems to try to compile C files for x86 target architecture.
When instead runningPKG_CONFIG_ALLOW_CROSS=1 CARGO_BUILD_TARGET=aarch64-alpine-linux-musl makeit fails somewhere with (not sure if the specified environment variables do help with anything):error[E0463]: can't find crate for `serde_derive` which `serde` depends on --> /home/pmos/.cargo/registry/src/github.com-1ecc6299db9ec823/cbindgen-0.14.4/src/lib.rs:9:1 | 9 | extern crate serde; | ^^^^^^^^^^^^^^^^^^^ can't find crate error: aborting due to previous error For more information about this error, try `rustc --explain E0463`.Maybe some of these search results for "openssl-sys" in Alpine could help, there seem to be patches to use the system's openssl library (though not sure if it currently tries to use a vendored openssl).
If anyone wants to pick this up, here is my APKBUILD so far.
By pcworld on 2021-07-27T23:49:11
-
Have you looked at the Arch pkgbuild? https://github.com/archlinux/svntogit-packages/blob/packages/libetebase/trunk/PKGBUILD
By tasn on 2021-07-28T08:40:37
-
It's trying to use the system openssl. This is how to vendor it: https://github.com/etesync/etebase-py/blob/master/Cargo.toml#L22
By tasn on 2021-07-28T11:55:46
-
It doesn't appear to help (though would I need to somehow regenerate the Cargo.lock? I'm not familiar with cargo).
And I assume Alpine would prefer to use system openssl rather than bundling it.Here is the full build output
(with the vendored openssl, but it doesn't seem to make a difference). I don't know why it assumes x86 architecture there (which is why it passes the inappropriate-m64argument).Edit: I was wrong, the output was without vendored openssl. When applying this patch to libetebase, the build output becomes https://gitlab.com/-/snippets/2154724
By pcworld on 2021-07-28T12:44:34
Edited by Administrator -
I have done that, now the build of
ringfails because it is also trying to build for x86: https://gitlab.com/-/snippets/2154738I wonder whether cargo currently tries to compile everything for x86 and it just fails for external C stuff because the gcc targets aarch64 by default, see also the following from the output linked above:
TARGET = Some("x86_64-alpine-linux-musl")
I have also tried to patch the Makefile's cargo command tocargo build --release --target aarch64-alpine-linux-musl, however then building the crates fails witherror: Option 'target' given more than once, I don't know why, in the process list--targetseems to only be given once in each cargo/rustc command line: https://gitlab.com/-/snippets/2154743By pcworld on 2021-07-28T13:08:59
-
It's an issue with pmbootstrap. I am now running this on Alpine's CI instead, and it works fine. As these packages should go into Alpine anyway, there will be no need to make it work using pmbootstrap.
Thanks for your help. I'll try to finish up libetebase and evolution-etesync and send a MR to aports (Alpine).By pcworld on 2021-07-28T14:53:03
-
I have opened a merge request in aports for libetebase and evolution-etesync. I have successfully tested this on postmarketOS Edge on a Pinephone: In Evolution's accounts dialog, I can add an EteSync account and it successfully syncs tasks and calendar events.
As it's difficult for me to commit to maintaining these packages long-term, maybe someone is interested in taking over maintenance of these packages in aports, in that case please comment on my merge request.
By pcworld on 2023-04-20T14:01:49
Edited by Ghost User -
I'm not an alpine user, so would be hard for me to take over. Though I think that given that maintenance in this case is fairly low-touch it's not that big of a concern, is it? People can always fill in and maintainers change, that's common in the Linux distro world no?
By tasn on 2021-07-29T08:57:19