Can't install from pip or compile binaries

[julianfairfax]

etesync-dav fails to install from pip and fails to compile from source.

This is an issue because the last amd64 binary is from a year and a half ago, the last arm64 binary is from two and a half years ago, and it should be possible to compile the binaries, as this is open source software.

Both operations fail with this error:

         Compiling time v0.1.43
           Running `rustc --crate-name time /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.43/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=7e9ffa02593b34c0 -C extra-filename=-7e9ffa02593b34c0 --out-dir /tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps -L dependency=/tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps --extern libc=/tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps/liblibc-94804d8bea296f0d.rmeta --cap-lints allow`
      error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
         --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.3.12/src/sockaddr.rs:176:9
          |
      176 |         mem::transmute::<SocketAddrV4, sockaddr_in>(v4);
          |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          |
          = note: source type: `SocketAddrV4` (48 bits)
          = note: target type: `sockaddr_in` (128 bits)

      For more information about this error, try `rustc --explain E0512`.
      error: could not compile `socket2` due to previous error

      Caused by:
        process didn't exit successfully: `rustc --crate-name socket2 --edition=2018 /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.3.12/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=5d6c35b38d40e4aa -C extra-filename=-5d6c35b38d40e4aa --out-dir /tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps -L dependency=/tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps --extern cfg_if=/tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps/libcfg_if-f05b0dcac0159f2d.rmeta --extern libc=/tmp/pip-install-v2q73ukh/etebase_19a952c3d63344b79495c3aa6630f831/target/release/deps/liblibc-94804d8bea296f0d.rmeta --cap-lints allow` (exit status: 1)
      warning: build failed, waiting for other jobs to finish...
      error: `cargo rustc --lib --message-format=json-render-diagnostics --manifest-path Cargo.toml --release -v --features 'cpython/extension-module cpython/python3-sys' --crate-type cdylib --` failed with code 101
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for etebase
  Building wheel for etesync-dav (setup.py) ... done
  Created wheel for etesync-dav: filename=etesync_dav-0.32.1-py3-none-any.whl size=56508 sha256=fbcea28d98ff4129508ef78d8e048904d8fdfb46a8d7a9f623e291b2290d77d3
  Stored in directory: /home/user/.cache/pip/wheels/74/49/94/981cac949fc13ffb7982b7afc3a389c5e83d44ea7231eb4365
Successfully built etesync-dav
Failed to build etebase
ERROR: Could not build wheels for etebase, which is required to install pyproject.toml-based projects

pip install etesync-dav log: log1.txt

git clone https://github.com/etesync/etesync-dav && cd etesync-dav && python -m pip install --upgrade pip pyinstaller wheel && python -m pip install -r requirements.txt . log: log2.txt

This situation leaves two options:

1. Use the binaries
2. Build etesync-dav and etebase-py from source, as the AUR packages do

Option 1 is problematic for the reasons previously described.

Option 2 has two problems of its own:

1. Python packages are version-dependent. As such, your build device and target device have to be the same. This isn't an issue for AUR packages, but is for Debian, for example. Packages built on stable won't work on testing, and the vice-versa
2. Python packages have dependencies. This is fine, but it's a lot nicer to install one singular binary file

Hopefully this is something that can be easily fixed, so that I can build a singular binary file for my amd64 and arm64 devices.

Thank you for making EteSync!

[julianfairfax]

See https://discuss.privacyguides.net/t/restore-etesync-calendar-contacts-sync/11764/31

[tasn]

I disagree with your statement there, but each to their own. :|

[julianfairfax]

I disagree with your statement there, but each to their own. :|

Well obviously I am quite sad I felt the need to make it. EteSync is conceptually unmatched in privacy, and I don't have any good options lined up to replace it yet. But, I find this issue here relatively problematic in terms of trust and security, since I can't rebuild the code, and the download options provided are very out-of-date.

And https://github.com/etesync/android/issues/238 makes it literally impossible for me to use EteSync at all. I have no doubt it's fixable, and I assume you probably will fix it. But, the pace of development on EteSync has at least slowed significantly, if not stalled. This is only one example.

I love(d) your service, but if I can't build its code, can't install up-to-date binaries, and can't even use it, then I love it less.

[tasn]

This is a desktop client on arm64. I understand that this is what you use and it's important for you, but also I don't even have an arm64 Linux box, and neither do most people. It's hard to maintain all the platforms in the world and we have to draw the line somewhere, and if you're on arm64 you're unfortunately on your own at the moment. I'm not even sure what the problem is tbh, but it looks arm64 related.

[julianfairfax]

This is a desktop client on arm64. I understand that this is what you use and it's important for you, but also I don't even have an arm64 Linux box, and neither do most people. It's hard to maintain all the platforms in the world and we have to draw the line somewhere, and if you're on arm64 you're unfortunately on your own at the moment. I'm not even sure what the problem is tbh, but it looks arm64 related.

This is not the problem. The problems are as follows:

• EteSync is not frequently updated, which is a security issue.
  • For example then, the latest amd64 binary for etesync-dav is almost two years old. The arm64 part of the problem is that the latest arm64 binary is even older, but this is only a detail
• It is not possible to install etesync-dav from source or build it from source
  • As stated here, trying to install the pip package, or trying to build etesync-dav from source, on any architecture, doesn't work. This means there's no way to get a newer arm64 binary, sure, but it also means there's no way to verify the open source nature of etesync-dav, since you can't build the source code
• The EteSync app for Android doesn't seem to be able to sync anymore. I don't know what caused this, or how quickly it can be fixed, but it's very clearly a big issue

If these are addressed, more specifically the last item in the list, which makes EteSync unusable for me, I will withdraw my comment on Privacy Guides and advocate for its inclusion. I would definitely like to see more activity on the repos though, or an explanation as to why updates aren't needed for security. EteSync is a paid service, so I expect that it will be kept up-to-date and secure.

In its current state as of today, I cannot use EteSync at all. That is a problem, more of a problem than any of my comments or suggestions for it. I hope this changes.

---

I'm reopening this issue, since it seems it's the place you'd like to discuss things, and since perhaps you could figure out the issue with the pip package, and by extension building from source, and fix it.