Help needed : Build packages for main linux distributions, including systemd startup scripts

[tlaurion]

Everybody loves automatic updates and easy installation and integration. Security lovers and privacy lovers even more, not necessarily tech-savvy. General population wants to be able to just call apt and dnf and even click install from Ubuntu to get this working and then follow guide for Thunderbird, until a plugin exist that could also be installed.

Think end user UX!

[tasn]

As you hinted, there is a plugin in the works for Thunderbird, and potentially also for KDE and GNOME (Evolution) during GSoC: https://blog.etesync.com/summer-internship-opportunities-etesync-projects-in-both-gsoc-and-outreachy/

As for the packages, I completely agree. It's currently packaged for Arch (in AUR) and if memory serves also NixOS. There are maybe also packages for fedora and centos. I don't remember. Either way, packaging, unfortunately, is done by the distributions maintainers, and not externally, so in order to get it in distros, you would probably want to open a ticket in your respective distro's issue tracker.

As for systemd startups scripts: we have them in the repo, so it'd be very easy for the package to install them too.

Edit: @daftaupe, could you please elaborate on the state of packaging of etesync-dav for fedora/centos? Thanks!

[tlaurion]

Test packages are loved by users and testers, and spec files loved by maintainers, so that external builders can easily pickup and distribution maintainers just add those spec files in their distribution builders and sign packages for release !

[tasn]

Yeah, we would love having those (in addition to the ones we have), do you know how to package for any distro? PRs would be highly welcome.

[tlaurion]

Would suggest to put a tag: help needed to help you get people knowledgeable do those needed tasks that are not planned right now from core devels of this project!

Would also suggest to target developers that you know in your circles directly so that they can point people that they know can contribute directly to those issues so devel goes a bit more organic :)

[tasn]

@tlaurion, thanks, added the label too. I agree about the organic comment, there are already a few packages, we just need to make sure they are listed in the readme.

[daftaupe]

Edit: @daftaupe, could you please elaborate on the state of packaging of etesync-dav for fedora/centos? Thanks!

@tasn I haven't packaged etesync-dav (only the etesync server so far), as I'm not using it myself for now.

I can try to package if people are interested.

[tasn]

Ah, I must have misremembered. If you can take a look, that would be great! I guess it all depends on how many of the deps are already packaged for the respective distros...

[tlaurion]

@daftaupe ?

[daftaupe]

@tlaurion well it's hard to find the time at the moment, but I'll look into that sooner or later :)

[tlaurion]

@daftaupe ping!

[BeatLink]

Id be so happy to see a deb package. You can release deb packages on github releases or even better, create your own PPA. In both cases you dont need to wait on maintainers to integrate it first.

[tasn]

I'd also be super happy, and I'd even happily build the dep packages for each release, I just need someone to actually implement the deb package (so I can build it).

[tlaurion]

Meanwhile, this tool is unfortunately not useable by a team and require too much support. I'll move away of it. The cost of accessibility is too high for added security.

Please fix this so Etesync can reach its userbase. Meanwhile, let's not forget the real issue should be resolved upstream instead of depending on external tools ot mitigate the real problem.

[tasn]

@tlaurion, what do you mean by "require too much support"? I agree we should add more packages though. Not sure what you mean by "the real issue should be resolved upstream" as NextCloud can't and could never support end-to-end encryption.

[tlaurion]

@tasn :

@tlaurion, what do you mean by "require too much support"? I agree we should add more packages though.

Deploying and maintaining EteSync is not possible until tools required to use such tools exist and installation and configuration becomes automated on desktop level just like it was on smartphones; desktop being where most of tasks related to time management really happens; not smartphones where those are calendar and tasks users and executors. In a collaborator environment where multiple desktops end users participate in the creation of tasks and events content for others, the actual smartphone-only-easy-deployment-with-self-enrollment is more then problematic.

Not sure what you mean by "the real issue should be resolved upstream" as NextCloud can't and could never support end-to-end encryption.

Well, "can't" and "could never" are pretty strong claims, which were technical challenges resolved by etesync that should also be resolved upstream by NextCloud with enough awareness and will.

Most of NextCloud users are not even aware that calendar and tasks are not encrypted at all. If that awareness reached users and users needs met investment, that technical problem would be tackled, and the ideas behing etesync could be picked up by upstream project.

Data stored on remote servers could be encrypted just like etesync did it, with a client-side encryption mechanism being implemented to do the actual encryption/decryption upon stored data across users knowing the shared secret.

[tasn]

Deploying and maintaining EteSync is not possible until tools required to use such tools exist and installation and configuration becomes automated on desktop level just like it was on smartphones; desktop being where most of tasks related to time management really happens; not smartphones where those are calendar and tasks users and executors. In a collaborator environment where multiple desktops end users participate in the creation of tasks and events content for others, the actual smartphone-only-easy-deployment-with-self-enrollment is more then problematic.

I agree. We would love to have more of it. Though we are also focusing on making it so most people won't even need etesync-dav. Take a look at: https://blog.etesync.com/gnome-and-kde-etesync-projects-accepted-to-gsoc/ https://blog.etesync.com/etesync-thunderbird-add-on/

Well, "can't" and "could never" are pretty strong claims, which were technical challenges resolved by etesync that should also be resolved upstream by NextCloud with enough awareness and will.

Most of NextCloud users are not even aware that calendar and tasks are not encrypted at all. If that awareness reached users and users needs met investment, that technical problem would be tackled, and the ideas behing etesync could be picked up by upstream project.

Data stored on remote servers could be encrypted just like etesync did it, with a client-side encryption mechanism being implemented to do the actual encryption/decryption upon stored data across users knowing the shared secret.

Let me clarify what I meant: of course NextCloud could mimic EteSync. Heck, they could just take EteSync itself and just run it inside NextCloud, so of course this is not what I meant.

What I meant is that NextCloud is a DAV server. They are all about compatibility with existing implementations and following this standard, and thus are very unlikely to implement end-to-end encryption until there's a widely adopted standard.

[tlaurion]

Edit: @daftaupe, could you please elaborate on the state of packaging of etesync-dav for fedora/centos? Thanks!

@tasn I haven't packaged etesync-dav (only the etesync server so far), as I'm not using it myself for now.

I can try to package if people are interested.

@daftaupe : how is the packaging going? (debian-10/fedora-32)?