Package etesync (and its dependencies)

I have installed and tested etesync on my openwrt router. I want to share the packages for etesync and its dependencies that are not in the official feed. But I am new in contributing. Do you have mentors or so? Right now I have the following questions:

  1. How should I publish the packages: All of them as one pull request or separately?
  2. The README.md of https://github.com/etesync/server-skeleton suggest to install it via virtualenv. But I made packages for the (missing) dependencies, too. Would it be advisable to use a virtualenv instead?
  3. Is there a how to make a package uci compatible?
    Could anybody look over my changes and give me feedback?

Posting your changes to Github on a topic branch (something not called master) is a good way to collaborate and get some input before a formal PR.

Thank you for your answer, I made the following topic branches:

The latter one is for moving the luci on nginx related files from the nginx and the uwsgi-cgi package to the luci-nginx and luci-ssl-nginx package. I would make this change only if @Ansuel approves it since it is his project.

This is a first proposal and there are some points still missing:

  1. Install etesync to another folder (instead of /etesync-server). What would be the canonical place?

  2. Maybe add uci support and a luci app for etesync, mainly for configuring the server name; there is already a admin interface build in for user management.

  3. Create a self-signed certificate and enable ssl in the etesync server section of the nginx configuration.

  4. I am not sure how to interact with the nginx configuration. Do you have any suggestions? Would it help to make it available via uci? Or would that be a bad idea or difficult?

  5. Etesync starts a uwsgi instance; how can I restart it after an update of uwsgi? Would that be a good idea at all?

  6. Autostart etesync by: uwsgi --ini /etc/uwsgi/sites/etesync.ini

  7. Define appropriate conffiles to control files on update and remove.

I appreciate other suggestions for improvement, too.

Think that talk on a pr is better

I put a lot of changes into one commit, would it be better to split it up? If so, how fine, every dependent package one commit? I would do that in another branch of peter-stadler/packages.

@Ansuel: Do you think, I should make a PR already? I would at least complete points 3 (ssl certificate) and 6 (autostart), and do some work on point 7 (conf files) before.

@jeff: I think I am in the wrong subforum, I intended to post this topic to Community Builds, Projects & Packages. Should I post it there, too?

At least at this point, the questions seem to be ones that "developers" can answer. At least as I understand it, the "Community Builds..." section is for content that end-users can download and install (without building it themselves) and for support of such content.

I understand, thank you :slight_smile:

Do a draft pull request this way we can see changes more easily
(If it's not a problem)

1 Like

I, personally, would include [RFC] in the title to minimize the wrath of the core development team.

So, I will do a PR tomorrow after working out and testing the points 3, 6 and maybe 7.

Thank you both very much.

1 Like

I made the PRs hoping they can be understood:


and